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