基于自主权的版本规划

原则：每个版本由"系统拥有多少 agency、你愿意放弃多少 control"来定义，而不是由 feature set 定义。把宏大的终局拆成可评估、可迭代、可逐层加码的早期行为。

步骤：

1. 找出高控制/低 agency 的 v1 能力：小、可测试、易观察——从"容易验证、人容易否决"的简单决策开始。
2. 规划 agency 逐版本递增的阶梯（每版只上一格）。
3. 为当前版本建 reference dataset（输入、应有输出、决策元数据），冷启动收集 20-100 条（历史日志或构造样例）。
4. 在每个版本停留到收集够真实行为信号为止，再放下一格控制。

三个示例阶梯：

• 客服自动化：v1 只做工单路由到正确部门 → v2 给人工坐席建议解决方案 → v3 限定范围内自动解决 + human fallback。
• 营销助手：v1 按 prompt 起草文案 → v2 搭建并运行多步 campaign → v3 自动投放、A/B 测试、跨渠道优化。
• 编码助手：v1 行内补全与样板片段 → v2 生成大块代码（测试/重构）供人审 → v3 自主应用范围内改动并开 PR。GitHub Copilot 和 Cursor 就是这样爬上来的——用户只看到当前形态，底层是一步步挣上来的。

直接跳 v3 的反例（为什么要爬阶梯）：退款请求被误标为计费问题 → 系统拉错 SOP → 生成貌似合理实则错误的回复 → 用户困惑、信任流失。eval 虽报警，但你要拆解一条纠缠的失败链：终点是生成错误，起点在路由，中间被缺失上下文放大。逐版本走则每层失败被单独暴露和理解：v1 教会你用户如何表述问题、哪些部门易混淆、什么元数据真正有用；v2 暴露检索在哪坏、哪些文档要更新；到 v3 你已知道哪些查询可安全自动化、哪里需要 fallback。