我曾把一个看起来很明确的任务交给 AI：阅读 verl 代码，参考已有 GRPO 脚本适配 Kimi3 的减层训练，并在 NPU 上跑通第一个强化学习优化步。两天后，AI 仍在换软件版本、调整层数和重跑 OOM。真正棘手的不是“还没成功”，而是我无法回答领导接下来一定会问的问题：卡在哪里、解决过什么、时间花在哪里、还能不能解决、还要多久、代码是否上仓、中文设计文档在哪里？

这促使我把 Goal 从一句终点描述改造成一个工程控制面：用 goal-definition 先与用户签订任务合同，再让每个 Goal 强制携带 goal-execution，按证据等级执行有界循环。最终目标仍然重要，但每一轮都必须留下新的事实、排除一个原因，或形成一个可交付成果。

多局点、多任务、多角色同时推进时，真正稀缺的不是勤奋，而是 判断力、取舍能力和可复用记录。均匀响应所有任务只能保证不出明显纰漏，却很难形成个人优势；优势通常来自少数高风险、高杠杆、高不确定、强依赖的局点。

本文把工作链路整理成一个可执行系统：先识别重点风险局点，再拒绝低优先级任务；先快穿刺关键假设，再并行派活和紧跟踪；先用原理、显存、性能 MFU 和投产约束做建模，再用实践验证、详细记录和持续修正形成历史；最后把优势进展、后续风险和必要求助稳定汇报出去。

这篇文章记录我当前的 Work with AI 文档工作流：不是把一段 prompt 扔给模型、得到一篇孤立文章，而是把调研、来源管理、论文图表、正文插图、图片上传、Hugo 写作规范、可复用 skill 和 git 发布串成一个可验证的流水线。

这条流水线的关键变化来自 Karpathy 的 LLM Wiki 思路：把知识库视作一个由 LLM 维护的 Markdown 代码库。原始资料进入 raw 层，结构化理解进入 wiki 层，Hugo 文章只是最终发布层。这样每次写作都会沉淀可复用记忆，而不是从聊天记录里重新发明一次。