AI 能编写更多代码，但系统工程仍需工程师负责

当人们说 AI 改变了软件开发时，我想知道他们指的是哪一部分。生成实现代码？探索设计？判断一个系统是否解决了该解决的问题？

这些活动彼此相关，但自动化其中一项并不能解决其他事项。我的观点是，智能体可以承担更多实现工作，并协助分析、设计和测试，而工程师仍负责决定要构建什么，以及需要何种证据才足以验收。

这会改变工作方式，但不会让责任消失。

我不太愿意把这描述成取代那个不断产出代码的人。这样会把开发者简化为打字，低估智能体能够协助的范围，并把任务自动化变成有关就业替代的说法。有关劳动力被取代的主张，需要令人印象深刻的演示之外的证据。

我更感兴趣的实际问题是：如何使用这些工具，同时让我们的决策保持可见、让反馈继续有用？

让决策有处可存

对话很适合探索各种选项，却不适合作为架构决策唯一记录的存放之处，因为它十分脆弱。

模型上下文是有边界的。一次长时间会话可能会被摘要、压缩，或在恢复时只保留选定信息。摘要可能保留结论，却丢失使该结论合理的条件。“使用本地缓存”与“使用本地缓存，因为这个界面必须在没有网络连接时仍可使用”并不相同。

Anthropic 的 关于长时间运行智能体的说明 描述了跨越上下文窗口时的连续性问题，以及一种采用增量工作和持久化进度产物的方法。它还指出，压缩可能导致指令变得不明确。这是一份针对特定设置的供应商工程报告，并非对开发工作流的普遍比较。

我更倾向于为需要长期保留的决策设置一个简洁、易于审查的存放位置。一个 PROJECT_GUIDE.md 可以包含：

• 产品的目标和当前范围，包括明确排除的事项。
• 重要的系统边界，以及架构选择背后的原因。
• 质量期望，以及用于检查这些期望的命令。
• 当更深层的决策需要更多篇幅时，链接到这些决策。

文件名本身没有什么特殊作用。智能体不一定会自动加载它。我会通过工具支持的项目指令将其接入，或明确把它纳入任务，然后检查智能体对它的理解。

对于每个增量，我会提供相关文件，并要求简要说明预期变更、约束条件和验收用例。转述是一个可以尽早发现误解的机会；实现仍须证明符合要求。

Simon Willison 的 2025 年 6 月关于上下文工程的讨论 有助于阐明如何为模型的下一步选择信息这一难题。我范围更窄的建议是，让这种选择成为有意识的决定，并检查其后果。

仅靠 Markdown 既不能保证检索，也不能保证遵从。每次任务都发送所有文档，可能会增加上下文和成本。选择性检索可以减少输入，但维护文档、检索文档和纠正错误也会消耗资源。任何关于节省的说法，都需要测量完整任务。

明确下一步行为

设想一个移动端搜索界面。这只是示例，不是已完成项目的报告。

这个故事或许可以这样表述：“作为用户，我希望搜索已保存的条目，这样无需滚动浏览整个集合就能找到所需条目。”首个增量工作的范围是对现有条目进行本地搜索。远程搜索以及对持久化机制的更改不在范围内。

实施之前，我会明确以下验收用例：

• 匹配的查询会显示预期条目。
• 没有匹配项的查询会显示空结果状态。
• 清除查询会恢复完整集合。
• 如果筛选是异步执行的，旧结果不能覆盖较新查询的结果。

这些用例暴露出一个技术问题：筛选是否真的需要异步处理？智能体可以帮助评估这一决定。我们应根据预期的数据规模和响应性要求来权衡，而不是因为模板要求就引入并发。

在这个示例中，我可能会选择单向数据流、明确的 UI 状态，以及将筛选逻辑与渲染相分离。这样更容易检查状态转换。其他系统可能有充分理由采用不同的结构；这是一种有明确目的的工程选择。

项目指南应保留这一目的。功能层面的说明应解释行为以及任何新的决策。它们无需复现整个架构。

增量完成后，我会检查差异、运行相关检查并实际操作界面。如果智能体在范围限制下仍重写了持久化机制，即使测试通过，这种扩展也不可接受。如果空状态看起来正确，但搜索匹配了错误的字段，截图同样无法证明正确性。

让生成结果经得起验证

智能体的输出具有概率性。验收应依赖于我们能够检查并在可行时复现的证据。

本地验证命令可以运行格式检查、静态分析、编译和聚焦测试。这些检查回答的是不同的问题。格式器检查约定；编译器检查语言和类型规则；测试则在特定条件下评估特定行为。没有任何一项能证明我们选择了正确的产品行为。

受控验证还需要受控输入。工具版本、测试夹具和执行条件都很重要。涉及时序、设备、网络或外部服务的测试可能会不稳定。声称测试套件具有确定性，并不会让它真的变得确定。

即使一项完全可重复的检查，也可能验证了错误的对象。搜索测试可能只断言出现了某个结果，却没有检查具体是哪一个结果。生成的测试可能忠实地编码与生成实现相同的误解。我会将断言与验收用例对照审查，并使用经过有意选择的示例，其中包括失败用例。

运行应用能提供另一类证据：行为在实际界面中是否合理。当性能很重要时，应在宣告成功之前定义衡量方式——设备、数据集、场景和阈值。对响应速度的快速直观感受是有用的反馈，但它不是延迟测量结果。

钩子可以让本地检查更方便，并更早发现错误。它们的覆盖范围取决于触发方式，以及能否被绕过。如果团队要求强制执行，服务端检查和仓库保护措施需要各自配置。本地钩子不等同于强制执行的远程策略。

最终仍由工程师决定证据是否足以支持接受、修改还是拒绝。智能体可以帮助收集证据；但它不能靠宣告成功，让一套不完整的测试变得完整。

文档必须证明自身值得维护

当一个小改动需要先经历一长串生成的文档，任何人才能看到可运行的行为时，我就会产生怀疑。每份文档都会变成需要审阅、调和和持续更新的内容。廉价生成文本，并不意味着廉价理解文本。

这是对比例关系和反馈节奏的批评。规格驱动开发有多种含义。Birgitta Böckeler 对 Kiro、spec-kit 和 Tessl 的 2025 年考察区分了几类做法：先编写规格、在维护期间保留规格，或把规格作为主要依据。讨论成本和掌控程度时，这些差异很重要。

François Zaninotto 对文档密集型工作流的批评通过所报告的案例提出了对审阅开销和指令遵循情况的担忧。这些案例是值得调查的线索。它们并不能证明规格通常会导致更差的结果。

增量式规格可以支持快速反馈。敏捷并不意味着回避文档：其原则强调频繁交付可运行的软件、追求技术卓越和适应能力。简短的验收案例可以服务于这些目标；当风险需要时，详细设计也可以。

更严格的规格对于安全约束、受监管的工作、公共接口、迁移兼容性以及跨团队协调可能很有价值。在这些场景中，一份简明指南是获取必要细节的入口。它无法取代这些细节。

我对文档的检验标准很实际：它支持哪项决策、实现或验证，又由谁维护？即使是解释一项兼容性约束需要好几页，我也会保留它。我会删除那些既不改变决策、也不帮助他人评估工作的重复文字。

Matt Pocock 的工程技能合集是另一个将指导打包成可适配、可组合模块的示例。我觉得这个方向很有用。它所声明的设计目标并不能证明，一套技能比另一种工作流表现更好。

明确作出验收决定

一个小增量仍可能包含错误假设。它的优势在于，能让我们更早、在更有限的范围内发现这种假设。

我主张的循环很直接：定义下一项行为，提供所需的上下文，核验理解，检查改动，收集证据，并决定是否接受。当决策发生变化时，更新长期有效的指导。如果审阅变得难以管理，就应先缩小增量或改进检查，而不是让智能体生成更多内容。

这种方法有其局限。它取决于工程师的理解、证据质量，以及保持指导内容同步的成本。本文提出的是一种实务立场，而不是一项受控研究或已证实的生产力提升。要证明这种提升，需要设置可比任务，并将审阅、返工、缺陷和维护成本计入考量，而不只是生成时间。

当我能够解释提出了什么要求、发生了哪些改动，以及为何证据支持验收时，我很放心把更多工作委托出去。这就是我希望带入 AI 辅助开发的工程标准。

你的工作流中哪些决策在对话结束后仍然可见——有什么证据能告诉你智能体遵守了这些决策？

作者说明：初稿在 AI 协助下生成，依据 Armando Picón 的论点并对来源进行了审查。Armando 审阅了文章并批准发布。西班牙语译文在 AI 协助下完成。移动端示例是虚构的。