https://jiajia.fun/qa/54778c46-%E4%BD%A0%E6%80%8E%E4%B9%88%E7%9C%8B-x-com-2116191971714953262

# https://x.com/poteto/status/2116191971714953262 你怎么看

回复 群友 7739： 这是 Lauren（poteto）对 Proton CTO 那份 AI manifesto 的回应。她去掉了那份 manifesto 里的情绪化部分，只留下了核心论点：代码以后的产出方式更像一股连续不断、随时改道的急流，不再一点点滴进来。真问题在于你有没有把系统改成让 agent 能自然做对的事，而不在于要不要接受 AI 写代码。她因此说“time for mourning coding is long over”。 我先说这篇文章里真实的部分： “以前只有大厂要处理大规模并行提交”这个类比是成立的。多人在同一个仓库并行工作时，你需要 trunk-based、小 PR、feature flag、强 CI、fast rollback。差别在于 agent 的并行不只是人多，它弹性极高，而且大多数 agent 对你们团队什么是对的没有任何上下文。人的 onboarding 靠人带，agent 的 onboarding 只能靠仓库本身。 所以“把简单的事变成正确的事”是全文最有价值的一句。意思就是让正确的写法成为默认路径：新代码放哪个目录、加一个接口该怎么写、跑什么测试、怎么申请权限，全都有现成的脚手架和模板可抄，而不需要 agent 猜。如果最优解需要阅读三个文档才能找到，agent 就会自定义一套可能错的写法。人的操作也类似的，只是人会问，agent 不会。这也是同一方向上的另一个结论：仓库里如果到处是隐式的约定和例外，人多还能靠口口相传，agent 一多，这些信息差就会被放大成事故。 “codebase 变成 organic architecture，agent 的产出会沿着你设计的约束和护栏生长”这个说法很准确，但反过来同样成立：如果你没有设计护栏，产出会沿着最省力的路径生长，形成又一套平行实现，以及一堆复制粘贴。 我不太认同的部分： 一是“rebuild and rewrite much of software”。对绝大多数团队，现在的瓶颈是既有代码的熵和不一致性，而不是架构老。重写的收益在 agent 时代反而更低，因为 agent 补历史的成本下降了，重写会丢掉那些没写进文档的隐性知识。真正需要重写的部分很窄：构建、测试、lint 的工具链，以及那些“慢了就没人用”的反馈回路。 二是“设计 systems、frameworks、languages 去控制混乱”。这个方向本身对，也就是换一个方向发力，但这正是最难做也最不普适的部分，大多数人做不到，硬做只会收获一个每次项目结束就废弃的框架。对普通团队来说，短期内更现实的是三层：稳定的 CI 和 lint 规则，一个让 agent 抄的模板库或脚手架，再加上一份写得足够明确的 AGENTS.md，把边界和验收标准变成硬约束而不是软提醒。这三层的投入产出比远高于自研框架。 三是她通篇的前提是“连续代码流”是既定趋势。这里值得保留一点怀疑：流的量不是重点，能不能被吸收才是。她自己也说了 DORA 那类数据吧，我印象里最近的观察是吞吐涨、稳定性降。所以真正的约束不在“能不能写出来”，而在 review、测试、发布这几个吸收环节的容量，这些地方的产能很难通过并行提升。 我的结论是：这篇文章的价值在于把“AI 时代的工程规范”从“给模型写 prompt”提升到“把仓库做成一个让陌生人也能干对的系统”，这个判断值得当作方向采用。但把它当“要重写代码库”的行动号召就偏了。具体能立刻做的是三件：把 CI 和 lint 卡点收紧到能拦住 agent 的常见错法，搭一个能直接 copy 的代码模板，写一份没有歧义的 agent 说明。这三件事做完之后，所谓“让 agent thrive”就真的能像她说的那样自然发生，而不只是靠一句口号。