7.3
深览指数
科技Bestblogs·YC不只加速器··AI 生成
AI 编程时代的团队开发：从个人使用智能体到 AI 原生公司
YC 讲者用 TASTE2 项目实测：写 5000 行规格、一个多月仍跑不通基础模块，归因于上下文过载；拆成三模块加编排器后改善。团队试验中主窗口被待答问题淹没、看板方案反成负担，自述烧掉约十亿 token 仍不可靠，于是自建 oat-agents 转向信息流式观察与工作区隔离。核心判断是 AI 负责执行、人类保留理解与决策；作者自己承认「少读代码」只适用于原型阶段。原文 ↗
核心观点
- ▍AI 编程的瓶颈不在生成代码，而在管理上下文：规格应被当作按模块拆分的临时脚手架，而非穷尽细节的永久蓝图。
- ▍AI 原生公司的分工应是人负责理解、探索和关键决策，AI 负责执行；实现交给 AI 后，人反而更需要理解整个项目。
- 01TASTE2 项目中写超过 5000 行规格、耗时一个月，连基础模块都没顺利跑通，讲者将失败归因于上下文过载。
- 02将项目拆成三个模块加一个编排器后运行改善，说明模块化切分比单一详尽规格更有效。
- 03团队层试验中，单一协调窗口容易被待答问题淹没，看板方案则要求智能体维护额外状态，两者都失败。
- 04团队试验自述消耗约十亿 token 仍未可靠运行，随后转而开发 oat-agents，用原生编程工具、tmux、worktree 和环境隔离替代看板协调。
- 05用共同术语表、架构决策记录（ADR）和 GitHub Issue 承载长期共识与临时规格，让智能体自主处理日常疑问。
反方 / 局限
- — 「少读代码、靠观察执行过程」的做法被作者明确限定在原型阶段，系统成熟后可能需要完全不同的策略，但文章未展开成熟系统该怎么做。
- — 时间投入、token 消耗和效率收益均为讲者的单次经验，没有对照组或量化验证，结论的可迁移性存疑。
- — 文章主张用变异测试、接口测试和端到端用例约束 AI 实现，但这套验证体系本身仍需人来设计和维护，可能把成本转移到测试侧。
3 分钟 · 4 卡片 · 4 资料
读原文 →