上周和一位研发负责人吃饭，他刚读完 Anthropic 那份《AI-Native SDLC Playbook》，兴奋又发愁。兴奋的是「原来代码不再是瓶颈这件事，连 Anthropic 都认了」；发愁的是——
「intent.md、spec.md、plan.md、三层控制、持续 Evals……这套东西我要是从零搭，得搭多久？我团队现在连个像样的需求管理系统都还在和 Jira 打架。」
我说，你可能不用搭。你已经有载体了：你的 GitHub Issue。
这篇文章写给研发团队 Leader，讲的是怎么把 playbook 那套六阶段闭环，落在你 今天就在用 的 GitHub 上——不新建系统、不加预算、不改变团队习惯。需要说明：下面那个贯穿全程的需求是 示意 walkthrough，用来把机制讲透，不是某个团队的真实战报；机制本身（Action 触发、产物链、门禁）都是 claude-code-action 和 GitHub 的原生能力，可直接照搬。
我的钉钉数字员工每个月偶尔会抽下风：「⚠️ 暂时无法处理你的消息，请稍后再试。」，往往重启一下就好了。今天我让 opencode + GLM-5.3 排查了下这个问题。
十五分钟后，它把案子破了。凶手很狡猾：藏在三份完美证词背后，还顺走了我的 /etc/hosts 当人质。
xAI 的 Grok Bot 发布页上，留着一条来自运营岗用户 Emma 的感言（译）：
「刚开始的时候，我每 15 分钟就要去查看一次 Bot，事无巨细地盯着它——直到它反过来问我，为什么我总是问这么多问题。现在我放手让它自己干，它反而越用越好。」
这可能是「数字员工」这个产品形态目前拿到的最好背书：不是一个等你提问的工具，而是一个你可以把工作交出去、然后转身去干别的事的队友。
但同一页往下翻，还有一行写给企业用户的小字：加入 waitlist。
喊得最响的「可以把真实工作交给它」，到了企业门口，只换来一句排队等候。这个反差值得认真对待：Grok Bot 上线 24 天，验证了什么？它又到底卡在哪？
先说结论： Grok Bot 验证了「持续角色」这个产品形态，但企业要的是「岗位」。从角色到岗位，差的最后一段不是模型能力，而是组织基础设施。 而这一段，恰恰是企业现在就应该开始在钉钉里上岗数字员工的原因。
写给 Agent 应用工程师。案例是这个仓库的
docs/runbook/：一条自动抄录与 Claude Code 的每一轮交互、再提炼成三份签入文档的管线。这篇讲三件事：它值在哪、怎么做的、以及 那份「提炼契约」里有哪些可以直接抄走的规矩。
这套 runbook 最大的价值不是「有了历史记录」—— 那部分靠会话 transcript 本来就有， 不用额外做任何事。它干的是一件更特殊的活：把「为什么现在的代码是现在这样」从某个 人的脑子里搬到版本库里，并且用机器去逼它对齐提交历史。
CLAUDE.md 自己写着这条链路的痛苦：「改动前先知道为什么是现在这样，否则很容易改回去」。
这个仓库改回去的代价特别高 —— 它有一串静默失败模式：eval 的 answer 闸门一旦放宽，
分数一夜之间虚高接近满分；泄漏闸门漏扫中文路径，整片文档静默地不在检查范围内；
--flatten 丢一个标记位，防自环就失效。每一条都是「当时为什么这么写」一旦丢了，
就会被「顺手改回正常」重新放出来的东西。而这些为什么大概率不在代码里，也不在任何
issue 里。
前两天我拿到一份文件：Claude 最新旗舰模型 Fable 5.1 在 claude.ai 消费端的完整系统提示词。不是泄露的片段，不是网友总结的版本——是完整原文。
274,608 个字符，超过 4 万个英文单词。
大多数人听到「系统提示词」会想到一段开场白：「你是一个乐于助人的 AI，请礼貌、安全地回答。」我以前也是这个印象。但把这份文件从头到尾读完之后，我改变了判断：
这不是提示词，这是一套个人操作系统。
今天和一个朋友聊天。他说自己做了一个非常精简的 Agent Harness，准备开源，让大家可以直接用。
我第一反应不是问他写了多少代码，而是问：
你看过 Pi Agent、OpenCode、DSH 吗？
他说，没有深入研究过。
那一刻我没有继续追问，但一个问题在我脑子里转了一下午：今天成为一个 Agent 应用工程师，真正重要的到底是什么？ 是能够自己写一个 Agent Loop，还是能够把 Agent 真正做成一个有价值、能生产、能赚钱的产品？
这篇文章把那条成长路线完整画出来。
半年前，我给自己上了第一批数字员工。上岗之前，我的想象是这样的：任务交给 Agent，我只管派活和收结果，我在钉钉上的时间应该大幅下降。
半年后，我打开自己的屏幕时间统计：我在钉钉上的时间没有下降——翻了一倍。
起初我以为是个体差异。但和几位同样在带数字员工的同事交流后，发现大家的处境差不多：Agent 越多，人在 IM 里花的时间越多。
这让我必须把一个判断写下来：
AI 不会造出新入口，只会加深你对旧入口的依赖。
最近读到一篇两万字的 Agent 自进化方法论，写得相当扎实。其中记了一条血泪教训：有团队在某个场景上连续 20 多轮自动迭代，效果一直不提升——最后发现根因根本不在配置层，而在工具层。20 多轮里，系统忠实地修 Prompt、改 Skill，每一轮都按评测信号在优化。
回头看，最惊人的不是根因藏得深，而是这 20 多轮里，没有一个人问过：这批评测 case 本身，选对了吗？
没人问，因为没人需要问——这份评测集没有主人。
这篇方法论（作者 yannisyang、ethanytzhou）把评测、记忆、落地、控制四个环节拆成飞轮：评测是眼睛，记忆是大脑，落地是手脚，人机协作是方向盘。四个齿怎么建、坑在哪、从零到一怎么落地，都讲了。它最有价值的一句话是：
大多数团队的问题恰恰在于：每个组件内部做得还行，但组件之间的「箭头」没有自动化。
飞轮的瓶颈不在齿，在齿与齿之间的通路。我完全同意——但沿着这句话再往下推一步，会发现一个这篇两万字没有回答的问题：
所有箭头里最上游的那一条——「什么叫好」——它的定义权在谁手里？
OpenAI 的创始人山姆·奥尔特曼，最近在一次专访里说了一段让我停下来的话：
现在有了 Codex，明明可以换一种办法工作，我却还在沿用以前的习惯。我不应该到处乱点，在不同的聊天软件之间复制粘贴，漫无目的地浏览邮件……然而，我的脑海里却根深蒂固地认为，做这些事情就是工作，就是高效。
注意这段话的主语。这不是一个对 AI 一知半解的传统行业老板，也不是一个拒绝新技术的保守派——这是做出 ChatGPT 和 Codex 的人，是这个世界上离 AI 最近的人。
他知道更好的办法。他手里就有那个更好的办法。他还是改不掉。
如果连他都这样，那「AI 会自然改变我们的工作方式」这个假设，就有必要重新审一遍了。
8 月底，麦肯锡的播客 McKinsey Talks Talent 里，主持人 Lucia Rahilly 抛出了一个很多公司都在回避的问题：Agent 进了核心工作流，谁来管它？
资深合伙人 Brooke Weddle 的回答很直接：「HR 管理的不再只是人类的绩效，现在还有数字员工。」 全球技术与 AI 负责人 Kate Smaje 接着把问题拆成了三问：
「我到底有多少个 Agent？谁对它们的绩效负责或担责？它们创造了多少价值？」
问完，她自己补了一句更狠的话：当她问企业「上次讨论非人类劳动力的绩效是什么时候」——「几乎没有组织能回忆起自己把这件事排上过议程。」
听到这三个问题的时候，我愣了一下——这不是新闻，这是我今年 3 月起就在博客里反复写的那一系列问题。麦肯锡用了整个 8 月，终于追上了这条线。
他们给出的答案也对：Agent 归使用它的业务负责人管，不是 IT，不是 CTO。 这和我在数字员工的第一准则不是可控性里推导的主管制，几乎是同一个结论的两条路径——他们从管理实践归纳，我从问责公理演绎，殊途同归。
但这份答案只答了一半。
[Read More]