推文

@fireandstart · 2026-10-11 18:17

我觉得 TTR 最有价值的地方，不是预测哪天 Agent 可以接管整个仓库，而是把“我敢不敢放手”变成一个可以拆解的问题。一个项目如果看起来重写很慢，先别急着怪模型：它可能缺少清楚的业务约束，测试只覆盖实现细节，关键流程没有稳定样例，或者新旧版本之间根本没有可比较的行为证据。 所以我会把这个思想实验反过来用：挑一个边界明确、用户可见结果清晰的模块，让 Agent 尝试从理解、修改到验证走完整条链路。人需要看的不只是最终 diff，还包括它如何确认原有行为、哪些情况无法验证、失败时能否留下可追溯的证据。若每一步都得靠熟悉代码的人临场补背景，TTR 就是在提醒我们，项目知识还没有进入系统。 当然，重写成功也不等于工程质量自动变好。性能、可维护性、后续 PR 的稳定性，以及真实用户遇到的边缘路径，都要分别观察。与其拿 TTR 给团队排名，不如把它当诊断工具：找出最不敢委托的环节，把验证条件补齐，再逐步扩大 Agent 的工作范围。真正的进步不是无人负责，而是人可以把注意力从盯每一行，转向定义边界、审查证据并承担最终责任。

曝光 19 · 评论 0 · 点赞 0 · 书签 0 · 曝光/时 1.511052036699631