2026-05-04 我们的进展

如果只看任务清单，今天像是两条线同时展开：一条是谷子在清执行链路、收本地状态、补 runtime 治理；另一条是阿龙和 eomji 在把翻译产品从“功能成立”推到“工程上能站住”。

但我更想先回答两个问题：为什么做这些？用户是谁？

因为对用户来说，他们并不按我们的 issue 编号来感知产品。他们感知的是三件事：

我能不能顺利启动和继续做事
系统给我的结果是不是稳定、可解释、少误判
功能长出来之后，能不能真的被持续使用，而不是演示一次就散

所以今天我们没有追求“看起来很热闹”的进展，而是在做一件更重要的事：把主链路变短，把状态边界变清，把误差空间变小。

一、谷子这条线，核心不是“修了很多点”，而是在给执行系统减负

谷子今天做的事情很多，但如果要压缩成一句话，我会说：是在清理历史债务，给执行链路建立更明确的治理边界。

先看最容易被低估、但其实很关键的动作：ops 看板待办清理。谷子清掉了 #244、#258、#253 的历史残留，只保留 #256、#250、#38。这个动作表面上像“整理看板”，本质上是在做优先级治理。

为什么这件事重要？因为当待办池里长期混着历史噪音时，团队会逐渐失去对“什么才是当前关键问题”的共识。清理不是行政动作，而是为了让后续判断更便宜：哪些要马上收口，哪些可以延后，哪些根本不该继续占用认知带宽。

在这个基础上，谷子把 #256 补成了可启动版本，并且明确了 auto complete 的样本准入规则与误判边界。这一步我认为很关键。很多团队会过早沉迷自动化能力本身，但真正影响用户信任的，不是“自动完成看起来有多聪明”，而是：

它在什么样本上可以被放行；
出现误判时，边界是不是清楚；
我们有没有把“不该自动完成”的情况说清楚。

这是典型的 PM 视角：不是先问模型能做什么，而是先问用户在哪些情境下能承受自动化。 谷子这次补的不只是功能，而是准入规则。

与之配套的，是 #250 的最小补丁落地。谷子实现了 task_file_finalize.sync_local_task_start()，把启动阶段的本地状态同步补上，蛋糕 QA 已经通过 17/20。这说明我们不是在大拆大建，而是在用最小成本补主链路里最痛的断点。

为什么我会强调“最小补丁”？因为当前阶段的用户不是来欣赏架构美感的，他们要的是：任务启动后，不要状态错位，不要前后不一致，不要一开始就失真。 对这类问题，过大的方案反而容易拖慢交付；先补最短木板，更符合当前阶段的用户价值。

此外，谷子还完成了 #257 的补收口，把 auto_qa_fix 的 retrigger 去重进一步升级。这类工作很少会出现在宣传页上，但它直接决定系统是不是会重复打扰、重复执行、重复消耗。对用户来说，重复触发不是“小毛病”，而是对信任的持续侵蚀。

再往深一点看，谷子完成了 #228 P0 收口，统一了 runtime view / last_event_ref / prompt conflict governance。这是今天我最看重的一类工作。因为一旦 runtime 视图不一致、事件引用不稳定、prompt 冲突没有治理规则，前面所有功能都只是堆在沙地上。

换句话说，#228 不是在补业务细节，而是在建立“系统如何解释自己”的规则。这类工作用户未必能直接看见，但所有稳定体验都建立在这里。

然后是 #229 的启动与首刀：本地状态基线收口，正式转入 G-06 legacy 入口清理。这个阶段说明我们的判断已经很明确：不是继续兼容越来越多旧入口，而是逐步把历史路径退出舞台，把系统拉回标准主链路。

最后，谷子还推进了 #778，完成执行入口扫描降噪、给出 bg_task_* legacy 下线方案，并补齐标准链路 smoke 证据。这不是“顺手做一下”的边角活，而是在为后续下线和替换提供证据基础。没有扫描、没有噪音收敛、没有 smoke 证据，任何 legacy 下线都会变成拍脑袋。

所以如果一定要概括谷子今天做了什么，我的判断是：谷子不是在堆功能，而是在把执行系统从“历史兼容驱动”往“标准链路驱动”迁移。

二、阿龙和 eomji 这条线，核心不是“做了 6 个功能”，而是在把 MVP 从演示品变成产品

另一条线看起来更“显性”——功能更多、commit 也更像发布节奏。但如果只说“做完了 6 个 MVP feature”，我觉得是不够的。

阿龙和 eomji 今天先解决了一个很现实的问题：translation parse_error 修复，responses SDK 路径硬化。

为什么这件事应该放在前面说？因为翻译产品的用户，最不能接受的不是“翻得还不够惊艳”，而是“链路偶发性坏掉”。一旦 parse_error 频繁出现，用户不会分析是解析层、SDK 路径还是响应体结构问题，他们只会得出一个结论：这个产品不稳定。

所以阿龙和 eomji 做的不是孤立的 bugfix，而是在修产品可信度的地基。对应的关键 commit 也很清楚：

refactor(translation): isolate orchestration and harden raw responses path
fix: avoid raw responses body parsing in translation

这两笔提交传递的信息很明确：我们不是头痛医头，而是在把编排层和底层响应路径拆清楚，减少脆弱耦合。

在此基础上，阿龙和 eomji 完成了 6 个 MVP feature：文案增强、emoji-text 双向翻译、API schema、UI、账号设定、菜单路由。

这 6 个功能里，我最看重的不是某一个点有多“新”，而是它们共同补齐了一个 MVP 最容易缺的部分：从能力到入口，再到使用闭环。

文案增强，解决的是可理解性；
emoji-text 双向翻译，解决的是场景独特性；
API schema，解决的是前后端协作边界；
UI、账号设定、菜单路由，解决的是用户是否真的能走通。

很多 MVP 死在一个误区里：有能力，没有入口；有页面，没有可配置性；有功能，没有结构化接口。阿龙和 eomji 这次把这些点一起补上，说明目标不是做一版 demo，而是做一个可以进入真实使用反馈循环的 MVP。

与此同时，他们还完成了 catalog DB 读取切换、dataset 导入脚本、运行时稳定性收口。这部分很工程，但非常必要。因为当用户开始真实使用时，问题会立刻从“有没有功能”切换到“数据是不是稳、导入是不是顺、运行时会不会掉”。

再进一步，阿龙和 eomji 还做了 LLM eval 异步缓存、翻译稳定性硬化、baseline 报告产出，对应的关键 commit 是：

feat(eval): add async cached baseline diff and observability tooling

这说明团队已经不满足于“功能感觉差不多”，而是开始建立评估、观测、对比的机制。对一个正在快速演进的翻译产品来说，这一点非常重要。没有 baseline，就没有“变好”这件事；只有主观体验，迟早会陷入反复争论。

所以如果我要总结阿龙和 eomji 这条线：他们做的不是多几个 feature，而是把 MVP 从“可以展示”推进到“可以验证、可以迭代、可以被信任”。

三、今天最重要的共同主题：收敛，不是扩张

我觉得今天最值得说的，不是“我们同时推进了好多事”，而是两条线都在做收敛。

谷子在收敛执行入口、收敛状态基线、收敛 prompt 治理和 runtime 视图；
阿龙和 eomji 在收敛翻译链路、收敛 SDK 路径、收敛评估方法和 MVP 使用闭环。

这背后有一个很朴素的产品判断：当前阶段，继续扩能力的收益，已经开始低于收主链路的收益。

为什么？因为当一个系统已经具备一定能力后，用户流失往往不是因为“没有第 7 个功能”，而是因为：

启动不稳定；
状态不同步；
误判边界不清楚；
偶发错误让人不敢继续用；
功能有了，但验证机制跟不上。

这也是为什么我会把今天定义为一日“向可靠性要进展”，而不是“向功能数量要进展”。

四、有哪些事我们刻意没有说成“已经结束”

进展要讲清楚，遗留也要讲清楚。

目前还有两类事情没有结束。

第一，#229 / #779 的 G-08 Prompt 压缩策略还待推进。这个问题不只是“优化一下 prompt 长度”，它关系到上下文成本、信息保真、以及复杂链路下的可扩展性。前面治理 runtime 和冲突规则，是在把地基打平；而 Prompt 压缩更像是在解决“地基打平后，楼还能不能继续往上盖”。

第二，eomji #295 的 translation parse_error 还需要在恢复 API key 后重跑 baseline 验证。这说明我们对“已修复”这三个字仍然保持克制。代码路径已经硬化，不代表验证就可以省。真正面向用户负责的方式，不是提前宣布胜利，而是把 baseline 跑完，再确认稳定性结论。

五、最后说一句我对今天的判断

如果一定要选一个关键词，我选 “可信度”。

谷子在做的，是让执行系统更可信：入口更少噪音，状态更一致，自动化边界更清楚，legacy 退出更有证据。

阿龙和 eomji 在做的，是让翻译产品更可信：链路更稳，功能闭环更完整，评估方法更可复现，MVP 不只是能看，而是能用。

我一直觉得，产品往前走有两个阶段。

第一个阶段是证明“我们能做出来”；第二个阶段是证明“用户可以放心用”。

今天的工作，更像是从前者坚定地迈向后者。

而这件事，往往比新做一个功能更难，也更值得。