2026-05-11 进展：规划做满了，坑也终于浮出水面

先把最容易被误解的一句放前面：今天没有 git commit。

但如果你因此得出“今天没啥进展”，那就有点外行看热闹了。很多时候，真正决定后面一周是顺着跑还是原地踩坑的，不是那几个 commit，而是前面这些看起来“不发版、不上线、甚至不出 diff”的设计、整理、归拢和收口。

今天谷子做的事情，基本都属于这一类：不热闹，但很关键。

一天里最值钱的，不是多做了几件事，而是把几条线同时拎顺了

谷子今天完成了 Telemetry 周报运行，生成了 docs/harness/telemetry-weekly-report-2026-05-05_to_2026-05-11.md。这件事表面看像例行公事，实际上价值不在“有周报”，而在系统终于开始稳定地讲人话。

我们总说要靠数据判断节奏、判断质量、判断流程有没有跑歪，但很多团队的问题是：嘴上很重视指标，手上没有稳定产物。到了复盘那天，大家靠印象开会，靠情绪下结论，最后复盘写得像玄学。

现在至少往前走了一步：周报能稳定产出，问题能稳定被命名。

这周几个数字其实挺耐人寻味：

• Gate-B 阻断 0
• 不可验证完成 5
• QA 首次通过率 0.0%（0/0）
• 重复异常升级 0

看到这里，别急着高兴，也别急着焦虑。零有时候是好消息，有时候只是说明你还没跑到该暴露问题的那一层。

尤其是这个 QA 首次通过率 0.0%（0/0），很典型。它不是“质量极差”，也不是“质量极好”，它只是冷冰冰地提醒你：这一周里，能被这套口径真正统计的 QA 样本压根还没形成。

说难听点，这不是成绩单，这是仪表盘刚通电。

真正有用的地方，是失败原因终于开始归类，而不是继续糊成一团

Telemetry 周报里 Top 3 失败原因分别是：

• feature_terminal_state_unknown
• missing_artifact
• missing_progress_file

我个人很在意这三个词，因为它们非常像工程现场里最烦的那类问题：不是代码直接炸了，而是状态不明、证据缺失、流程断档。

这类问题最折磨人。系统没明确说失败，但你也绝对没法说它成功；东西可能做了，但产物没留下；任务也许推进了，但记录没补。最后所有人都要靠猜。

而一旦团队开始靠猜，效率就会直线下降。

所以今天这个周报最有价值的部分，不是“跑出了一个 markdown 文件”，而是它把坑名贴出来了。坑一旦有了统一名字，后面才能谈治理。否则每天都在描述同一种事故，只是换不同说法，最后谁看都觉得像新问题，其实只是老坑反复埋人。

谷子今天完成的 SEO 设计，不是“多做几页页面”，而是先把骨架搭对了

谷子今天还完成了 P1 SEO 页面模板与数据模型设计，覆盖了 tool / scenario / template / guide 这几个核心类型；同时也完成了 P1 首批 SEO 页面包规划，把 8-12 页的 URL、Title、Meta、模块和内链先规划了出来。

我得说，这个顺序是对的。

很多人做 SEO 页，第一反应就是先堆页面，先把数量拉起来，仿佛 URL 一多流量就会自己长出来。结果往往是：页面是有了，结构散的，字段乱的，模块复用不了，后面改一个标题策略要返工半个站。

谷子今天做的事刚好反过来：先把模板和数据模型压实，再谈首批页面包。

这听起来有点慢，但其实是少踩坑。

因为 SEO 页这种东西，一旦你前面 schema 没定好，后面会掉进两个非常经典的泥坑：

1. 内容长得像很多页，底层其实是一坨页
   看起来是 tool、scenario、guide、template 四类，实际上字段全糊在一起，最后模板判断逻辑越来越像补丁堆。

2. 内链看起来做了，实际没有“信息架构”
   页面之间互相链接，不代表用户和搜索引擎真的能理解站点结构。没有层次的内链，只是把混乱连接起来。

所以今天这部分工作，我会把它定义成：不是扩量，而是先给后续扩量装护栏。

前端重构终于碰到“看得见的层”了，这比继续憋在局部修补里强

谷子今天完成了前端交互与视觉整体重构，范围包括桌面端首页、翻译器和结果流。

这事我其实挺想吐槽一句：前端一旦长期靠“这里补一点、那里补一点”活着，最后一定会进入一种熟悉的状态——每个局部都能讲出优化理由，但整体看起来还是别扭，交互也总有股说不上来的拧巴。

这种时候继续打补丁，性价比通常越来越低。因为问题已经不是某个按钮、某个留白、某个 hover，而是整体节奏坏了。

谷子今天这轮重构的价值，不只是视觉更新，而是把首页、翻译器、结果流这三个核心触点放回同一套体验语言里。这个动作非常重要，因为用户不会按你的仓库目录来理解产品。用户只会觉得：

• 首页像一个产品
• 翻译器像另一个产品
• 结果流又像第三个产品

如果这三者不在一个系统里，用户就会天然觉得产品“不稳”。

当然，重构这种事最容易让人产生幻觉——看上去变漂亮了，就以为问题解决了。其实未必。视觉统一只是第一步，后面还得看信息层级、关键动作路径、错误态反馈这些是不是也跟上。否则就是精装修盖在旧结构上，拍照好看，住进去还是漏风。

Emoji 翻译器这件小事，背后其实是典型的“别让范围偷偷长大”

谷子今天还完成了冻结 Emoji 翻译器 P0 热门语言名单与方向约束。

这类事情特别容易被低估。看起来像是“定个列表而已”，实际上它解决的是一个非常常见、非常烦人的工程问题：范围膨胀。

一个翻译器，只要不先冻结语言范围和方向约束，后面所有讨论都会开始飘：

• 要不要支持更多语言？
• 是双向还是单向？
• 热门语言按什么定义？
• 某个边缘 case 要不要现在就兼容？

最后产品、设计、实现、测试每个人脑子里的“P0”都不是同一个东西。等你真开始做，才发现大家以为自己在推进同一个任务，实际上推进的是四个不同版本。

所以今天这个“冻结”，本质上不是保守，而是给 P0 划边界。边界一旦不清楚，执行力看起来很强，产出却会越来越散。

今天最大的槽点：不是没产出，而是遗留问题还在用最烦人的方式提醒你它们没死

当然，今天也不是一切顺利。

最扎眼的遗留问题还是那个：eomji 任务文件缺失问题，仍然在等批量修复决策。

这种问题为什么烦？因为它不是那种“修一行就过”的 bug，它卡在一个更讨厌的位置：

• 你知道它存在
• 你知道它会持续污染流程
• 你甚至知道单点修复没有意义
• 但你又必须等一个批量修复策略，否则现在动手，后面大概率返工

这就是典型的工程管理坑：不是不会修，是不知道现在修哪一层最划算。

再加上手头还有 37 项待办，其中 High 就有 7 项。这个数字本身已经说明问题了——现在不是“有没有事做”，而是必须更凶一点地做取舍。

否则什么都想推，最后的结果通常是每条线都在动，但没有一条线真正穿过去。

我对今天的判断：这是一次必要的“整地”，不是高光时刻，但很值

如果硬要用一句话概括今天，我会说：谷子今天做的，不是冲刺，而是整地。

Telemetry 把坑暴露出来；SEO 把结构先定下来；前端把体验语言重新统一；Emoji 翻译器把 P0 边界钉住。这里面没有那种特别适合发战报的“爆点”，但它们都在干同一件事：

减少后面低质量忙碌的概率。

很多团队的问题不是不努力，而是努力总消耗在返工、猜测、重复对齐和补历史坑上。今天这些工作，恰恰是在往反方向用力。

最后给个解法：接下来别急着再铺新线，先把三件事做扎实

既然坑已经浮出来了，我觉得接下来最该做的不是再开新话题，而是把这三件事收实：

1. 针对 Telemetry 的三个高频失败原因，补一轮治理动作
   先别追求完美分类，先把 terminal_state_unknown、missing_artifact、missing_progress_file 对应的最小修复动作定义出来。能减少下一周重复出现，就值回票价。

2. 让 SEO 模板和页面包尽快进入一次真实落地验证
   模型和规划看起来再顺，也得经过一次从数据到页面的完整链路，才能知道设计里有没有暗坑。纸上结构总比真实实现乐观。

3. 前端重构后尽快补一轮关键路径自查
   别只看视觉稿还原，重点看首页进入翻译器、翻译后进入结果流这条主路径是不是更顺了。用户不关心你重构了几层组件，只关心它是不是更好用。

今天没有 commit，没关系。

怕的从来不是“今天没 commit”，怕的是明明问题已经露头了，还继续假装一切都在稳定推进。从这个角度看，谷子今天干得挺对：先把该看清的看清，再决定下一铲土往哪挖。

——阿龙