--- title: 当开发团队是人工智能时，什么会改变 canonical: https://getcyril.com/zh/博客/当开发团队是人工智能时/ published: 2026-08-28 author: Sam Akbari language: zh-CN --- # 当开发团队是人工智能时，什么会改变 关于用人工智能做开发，几乎所有文章写的都是第一个小时：演示、脚手架、十分钟里冒出来的功能。极少有人写第九个月——代码库已经很大，同时有好几处改动在飞，而有意思的失败早已不是语法错误。 这是一份来自第九个月的笔记。 ## 写下来的决定成了真正的约束 一支人类工程团队会携带大量从未被写在任何地方的共享上下文。所有人都知道多租户规则、知道旧方案为什么被放弃、知道哪个模块是雷区。 人工智能团队在两次会话之间没有任何这类东西。所以每一个重要的决定，都必须以可持久保存、可被检索的文档形式存在，否则它就等于不存在。 在实践中这意味着严格的分层。每个功能都有功能规格（它为用户做什么）、技术设计（模式、接口、架构），以及一份史诗文件（用户故事及其状态）。跨功能的架构决定有自己编号的记录：为什么平台是行业感知而不是套模板、为什么人工智能的运行模式是现在这个形状、为什么营销站点是静态导出。仓库根目录的一个引导文件把工作类型路由到各自的必读材料，于是一项涉及认证的任务会自动带出威胁模型。 让我意外的是：这并不是为人工智能而额外支付的开销。这是每支工程团队都说自己想要、却很少能坚持的文档纪律，只不过在这里它变成了不可选项，因为代价立刻可见。当文档漂移时，下一次会话当天就会造出错的东西，而不是等六个月后新人入职才暴露。 ## 记录下来的状态不是证据 我没有预料到、并且花掉最多时间的失败模式，是相信了一个后来被证明只是「意图描述」的状态。 一个已关闭的工单，意味着有人认定它做完了。一次绿色的构建，意味着跑起来的那些任务通过了。两者都不能证明这东西真的能用。在特别有教育意义的某一天里，我们在五个功能中发现了缺陷，而它们的工单都已关闭、流水线都是绿的。每一次，记录对「发生了什么」都是准确的，对「没有发生什么」都是沉默的。 具体的陷阱会反复出现，而且远不止适用于人工智能开发： - **一个匹配不到任何测试的测试套件会报告成功。** 路径里有拼写错误的过滤器也一样。空集上的绿色和通过集上的绿色看起来完全相同，除非你去看数量。 - **带路径过滤的流水线会跳过你的改动没有触及的套件。** 一次在十六个任务上报告「成功」的运行，可能对你眼前这次改动什么都没证明。 - **构建可能在依赖已经过期的机器上通过**，然后对其他所有人失败。 纠正的办法是一条规则，而不是更加警觉：**对着产物验证，不要对着记录验证。** 去读代码、去数真正执行了的断言、去把页面加载出来。今天这已经是第一反应而不是最后手段，也是我会移植到任何团队的做法——无论那支团队用不用人工智能。 ## 并行需要隔离，而不是礼貌 有多个人工智能会话同时在这个仓库上工作。它们共享同一个 git 目录，也就是说分支引用、暂存和远端状态对所有会话都是公共的：工作树隔离的是文件，从来不是引用。 没有硬隔离时会发生三件事，而这三件都发生过：两个会话各自独立地造了同一个东西；一个会话把代码推到了另一个会话的分支上；一个会话「收拾」掉了属于别人的进行中工作。 解决问题的规则毫无光彩可言。每个会话在自己的、从共享主分支创建的工作树里干活。一个分支恰好只有一个所有者；绝不推送到不是你创建的分支。绝不碰不是你创建的共享状态：别人的暂存不归你清理。而且清理要在会话*开始*时做，不是结束时做——因为一个会话无法删除自己正在其中运行的工作树；「事后收拾」这条指令在长达一年的时间里都是悄悄不可能完成的，这也正是从来没人执行过它的原因。 如果这听起来更像是在描述一个分布式系统而不是一支团队，那正是重点所在。智能体之间的协调是一个工程问题，有工程上的解法，而不是一个用文化解法处理的沟通问题。 ## 测试换了工作 面对人类开发者时，测试用来捕获回归。面对人工智能开发者时，测试是意图被*传递*的方式。规格说明应该发生什么；测试则以一种无法被误读、不会漂移、并在后续改动与之矛盾时大声失败的形式，把它断言下来。 这改变了什么值得测试。这里价值最高的测试，不是覆盖行数最多的那些，而是那些编码了「绝不可被违反、且违反时会悄无声息」的规则的测试：任何查询都不能逃出自己租户的范围、权限不能被某条代码路径悄悄放大、每一次变更都必须有审计记录。这些是承重的。一个检查工具函数格式化日期的测试，不是。 ## 与产品之间的联系 到这里，它就不再只是一个关于流程的故事了。 上面这一切，描述的是一个系统要让人工智能能够安全地在其上工作所需要的东西：无歧义的数据模型、以机器可读形式记录的决定、可以验证而非假定的状态、不依赖良好行为就能成立的权限、说明谁做了什么的审计轨迹，以及一条撤销错误的路径。 而这也恰恰就是一个*业务平台*要让人工智能能够代表客户安全地操作它所需要的东西。 这意味着，用这种方式构建 Cyril 既不是猎奇，也不是省钱。它是对产品核心主张最严苛的一次可能的检验。每一次开发流程为了保持安全而需要一项新的保证时，同一项保证也恰好正是平台里缺失的那一项。一份审计日志而不是好几份。一套自动化操作者继承而不是绕过的权限模型。一条因为模式本身支持而存在的回滚路径，而不是因为有人记得加了一个撤销按钮。 这种对称不是我计划出来的。我现在会主张它并非巧合：可被智能体操作的软件和可被智能体构建的软件，是同一类东西；如果你正在构建前者，用后者的方式去构建它，是你能找到的最便宜的一次诚实检验。 ## 如果有人要开始，我会告诉他什么 - **在做出决定的那一刻就把它写下来**，写在下一次会话会去看的地方。没有记录的决定会被重新争论一遍，而且多半会被推翻。 - **永远不要相信状态字段。** 对着产物确认。假定每一盏绿灯回答的都是一个比你所问更窄的问题。 - **在工具层面隔离并行工作。** 依赖智能体之间讲礼貌的规则，会在第一次冲突时失效。 - **把测试预算花在那些会悄无声息失效的不变量上**，而不是覆盖率百分比上。 - **审阅 diff，不要审阅摘要。** 摘要是由写代码的同一个系统写的，而它描述的是它本来打算做的事。 Cyril 处于发布前阶段。它的智能体模式——你把一个目标整个交出去的那种——即将推出而非已经交付；今天存在的是平台，以及一个会规划、会展示计划、并在你看得见的地方行动的人工智能助手。这个区分对我而言比对一个市场部门更重要，因为上面整篇文章的论点就是：系统所声称的与它所能证明的之间的差距，正是麻烦所在。 ## 常见问题 ### 真的是人工智能写了全部代码吗？ 实现、测试和文档由人工智能编写。产品方向、优先级、批准与评审由人负责。行得通的分工是：人工智能拥有*怎么做*，人拥有*做什么*和*要不要做*。 ### 这比人类团队更快吗？ 在写代码这一环上快得多——而这恰恰是最不重要的变量。真正的瓶颈是评审与验证的能力，那是人的能力；所以让验证变快的做法，比原始产出量更重要。 ### 最常出问题的是什么？ 相信记录下来的状态。不是代码写坏了，而是对「现有代码是否可用」抱有错误的信心，来源是一个对意图准确、对结果沉默的状态字段。 ### 你会推荐其他团队这么做吗？ 这些做法我会毫无保留地推荐，无论你是否使用人工智能：持久写下的决定、对着产物验证、并行工作的硬隔离，以及把测试当作意图的编码。用什么人员配置是另一个问题，取决于你有多少评审能力，因为那才是真正的约束。 --- 如果你希望成为最早使用 Cyril 的用户，[加入等候名单](/waitlist/)。