AI 的本质是概率分布。它学过那么多东西，但究竟该输出什么？AI 不会在你提问时输出小说，是因为它进行了情感与价值观的对齐。对齐的本质是在筛选，增加“正确”信息的权重。AI 现在如此好用，很大程度上是因为它继承了人类文化中“对”的部分。对人类而言，能抵御枪炮病菌生存下来、能造出钢铁就是“对”的，这是与现实交互后得到的优质信息。对于程序而言，能通过编译是“对”的，能在与计算机的交互中获取正向反馈也是“对”的。因此，要让普通的 AI 变得更好用，本质上就是要为其积累更“对”的信息，换句话说就是“Garbage in, garbage out”。

信息不只是新知，降低搜索空间本身也是信息。“无限猴子定理”或是棋类游戏的必胜操作虽然在理论上存在，但现实中的时间和效率都是有限的。在香农的信息论中，已知公理和推导出的结论所包含的信息量可以是等价的，但这有一个前提：推导过程不需要时间。倘若如此，现有公理与证明哥德巴赫猜想的信息量就是相同的。然而现实并非如此，我们必须通过引入信息来提高求解的效率。

在单次开发中，从获取信息的角度来看，不要试图纯靠自然语言让 AI “变聪明”，而要让它与编译器、操作系统发生强交互，比如让它多生成并分析 Log。不要只停留在文档层面的软约束。虽然业务逻辑高度依赖语义，但我们应该通过编写 Linter、声明代码模块的功能和作用域、编写 Gate 脚本来强制守住代码的底线（例如使用 Zod 或 Pydantic 等 Schema 验证库）。

Linter 的约束也是分层的。以 TS 开发为例：可以使用 ESLint 管控复杂度和深度，通过 no-magic-numbers 拦截硬编码；自定义 check-*.mjs 脚本来管理仓库规范，通过正则或 AST 强制 AI 调用已封装的函数，避免它重新造轮子；再利用 quality-gate 配合 pre-commit 保证提交前必须通过测试。应少写缺乏强制力的需求文档和容易滞后的代码注释，多写 Gate 脚本。例如，直接在工作区禁用原生的 git commit，强迫 AI 使用封装好的提交流程，自动执行测试和 Linter 检查，完全通过后才允许提交。

在开发效率上，对于上下文管理，告诉人不要去想房间里的红色大象反而适得其反，AI稀缺的注意力也会受到猫的影响，因此相比纠正AI，删除没必要或是错误context更加高效。要多写最小可行性 Demo 来排查问题。先跑通基础功能，证明代码方案可行、API 可用，从而排除开发环境等非代码层面的干扰。此外，项目初期就需要设定好可扩展的架构，模块化拆分后还能支持多 Agent 协同开发。技术选型时也应引导 AI 选择现代化的技术栈。开发过程中，必须杜绝无价值的冗余兜底代码，例如处理 API 返回值时，绝不能写出 name = data.username && data.user.info && data.user.info.name 这种离谱逻辑，这完全可以通过引入强类型、Linter 或单元测试来规避。当 AI 对逻辑不确定时，应要求它先去运行最小 Demo 进行验证 validation。大多数情况下，让 AI 直接阅读开源项目的核心源码比读官方文档更准确。同时，在新项目的重构中，应尽量舍弃历史兼容性包袱以提高代码准确度。为了进一步提升效率，除了提取代码中的可复用片段，更应该提取工作流中的可复用操作，比如将版本 release、环境启动等流程封装成自动化脚本。

在多次开发迭代的信息积累中，开发不仅仅是为了解决当下的 Bug，更要捕获那些能够降低未来搜索空间的信息。正所谓“一力降十会”，应尽量使用基座能力强的 AI。随着 context 的不断变大，早期的提示词工程可能会逐渐失效，但沉淀下来的工程经验依然极具价值。遇到问题不要修好就结束，而应考虑将其固化为 Gate 脚本或技术文档，避免同类错误再次发生。除此之外，Gate 脚本必须记录命中率 Log，以确保拦截规则是有价值的，不会过严或过宽。例如，若单文件代码行数限制被频繁触发，就需要重新评估该指标是否合理。

要让 AI 对未通过 Gate 检查的问题进行深度复盘。复盘绝不能流于形式，类似“抱歉，我没想到xxx”的口头表态毫无意义。核心是要准确记录犯错的原因，并持续构造项目的错误列表。Gate 脚本的“命中率 Log”只有在问题高频发生时才具备较大的统计意义。开发中遇到的长尾缺陷和边缘情况对于完善系统边界具有很高的参考价值，尤其是高频触发的 Edge Cases，更值得重点关注。

人机沟通的记录同样需要复盘，以整理出交互过程中的低效点。在复杂工程中，明确指示 AI“正确路径该怎么走”往往很难，但我们可以利用经验划定“绝对不能怎么做”的禁区。配合 AI 自身的概率平均性与随机性，在排除了错误选项后，它自然能探索出正确的结果。不仅是技术架构，AI 在执行任何任务时，都应该为后续的复盘预留数据接口。甚至，“复盘”这套机制本身，也应该具备持续自我迭代的能力。