上周在钉钉里看到一条消息，让我意识到一个根本性的转变正在发生。
一位产品经理在群里 @AI 助理：「帮我总结一下今天会议的要点。」AI 很快给出了回复。几分钟后，她又 @采购 Agent：「根据这份 PRD，生成采购计划并提交审批。」
同样是 @AI，但两次操作的性质完全不同。第一次是 问一个问题，第二次是 派一个任务。
这个细微的差别，恰恰是 AI 时代 IM（即时通讯）正在发生的最深刻的范式转移： 沟通正在从「对话」演进为「协同」。
Loop Engineering：AI Agent 工程的第五层
From Prompt to Goal — the human defines the finish line, the agent finds the path
4 月底，OpenAI 发布了 Codex CLI 0.128.0。更新日志里藏着一句话：「Added persisted /goal workflows with app-server APIs, model tools, runtime continuation, and TUI controls.」几乎同一时间，Claude Code 也上线了 /goal 指令。Greg Brockman 在推特上写了一句：「codex now has a built-in Ralph loop++.」
大多数人把这条更新当作又一个 feature flag 滑过去了。但如果你仔细拆解 /goal 的设计，会发现它代表的不是「又一个功能」，而是 AI Agent 工程的一次范式跃迁。
AI 表格做 Scrum 团队的大脑
AI-Driven Scrum Workflow with DingTalk Tables
周一早上 9:30，一个 5 人 Scrum 团队的钉钉群里，AI 表格自动推送了一条晨会摘要：
📊 今日待办 7 项 （P0×2 / P1×3 / P2×2）
⚠️ 发现 3 个支付模块 bug 集中在支付网关，关联上周五 v2.3.1 发布。建议优先处理 #BUG-042，指派给 @张三（支付模块 owner）。
🔗 需求 #REQ-015 与 #BUG-039 存在依赖关系，建议先完成 bug 修复再启动需求开发。
工程师张三看到这条消息，点进 AI 表格，看到 AI 给出的修复方案：「参考支付网关 v2.3.0 的超时配置，建议在 PaymentClient.java:128 添加重试策略，预计 30 分钟」。他结合自己的经验判断，觉得方案基本靠谱，但超时时间应该更短。改了参数，40 分钟搞定。CI/CD 跑完，AI 表格自动更新状态，群里推送：
✅ BUG-042 已修复（张三，40 分钟）→ 已部署 staging
这不是假设。用钉钉 AI 表格 + 群沟通 + dws CLI，这个工作流的每个环节今天都能搭出来。下面拆解怎么搭。
AI 改变工程效率的两件事，和其他所有没变的事
Code Gets Faster, You Get Parallel, But Judgment Stays Human
早上九点，我打开电脑，同时启动了三个 AI 任务：让 Claude 审查昨天提交的代码、让 Codex 生成单元测试、让另一个 Agent 整理技术方案文档。一个小时后，三件事都有了初步产出。
要是在两年前，这三件事需要一整个上午，甚至更久。
效率确实提高了。但我发现一个有意思的事情：当我放下 AI 产出物，开始做真正重要的决策——这个架构该不该拆、这个技术路线要不要换、这段代码的设计到底对不对——AI 完全帮不上忙。
这不是 AI 不够好的问题。这是工程效率的本质。
核心判断
我对 AI 时代工程效率的判断很简单：
本质上只有两件事发生了绝对的变化：
- 代码编写耗时——AI 直接生成代码，写代码本身变快了
- 单人任务从串行到并发——一个人可以同时跑多条线，像小团队一样运转
其他方面，还得靠人的品味。
[Read More]企业知识AI Ready的落地路径
Events Before Intelligence
周三晚上 9 点，供应链主管小林在钉钉里收到一条告警：「供应商 A 本周交货延迟率从 3% 升至 12%」。他看了一眼，回了句「知道了，季节性波动，不用管」。这条消息随即被淹没在后续 200 条群聊里。
两个月后，另一个团队的采购经理在审批供应商 A 的新合同时，完全不知道这段历史。合同正常通过。三个月后，供应商 A 果然出了大问题——产能不足导致全线延迟。
这个故事里， 信息是存在的——告警推了，人判断了，反馈也有了。但信息在人与人之间断裂了。小林的处理经验没有被结构化地沉淀下来，后来的决策者无从获取。
这正是大多数企业 AI 落地时撞上的第一堵墙： 不是 AI 不够聪明，而是企业的「神经系统」还没建好。
知识库编译查询：让 AI 从「读文档」变成「查数据」
Designing Knowledge Compilation and Query Methods for Better AI Analysis
上周五，我让 AI 帮我分析一场 90 分钟产品周会的听记转写稿——15000 字的会议记录，要求提取关键决策、未闭环的行动项、以及和过去三个月决策之间的矛盾。
第一次，我直接把转写稿喂给 AI，说「帮我整理会议纪要」。得到一份「看起来还行」的摘要：谁说了什么、讨论了什么话题。但这不是我需要的——我需要的是 洞察。
比如：技术负责人在讨论方案 A 时说「我觉得可以上」，但架构师追问了三个问题后，他改口说「那还是再看看」。AI 的摘要写的是「张总介绍了技术方案」—— 关键决策点被淹没了。
[Read More]反直觉：AI 时代，知识库工具越简单越好
Less is More: Why Simpler Knowledge Tools Win in the AI Era
上周我打开了尘封已久的 Obsidian vault。
50 多个插件，300 多个标签，12 个 database view，还有一套精心设计的 MOC（Map of Content）索引系统。我花了不知道多少小时在「组织」知识，而不是「使用」知识。
然后我意识到： 这套系统在 AI 时代已经过时了。
[Read More]SKILL.md 不是文档，是编译器
How a 900-Line Markdown File Turns AI From a Chatbot Into a Content Pipeline
「准备写一个 blog，详细讲解这个 skill。」
我对 Agent 说完这句话后，它在 0.5 秒内完成了三件事：加载 900 行 SKILL.md、扫描过去 127 篇博客的标题做交叉引用、按 Planner 模块输出了文章分类和大纲。没有追问「你想写什么角度」，没有问「用什么语气」，没有忘记中文排版要加空格。
一个会自己写博客的系统
From Squeezing Out Posts to Publishing at the Speed of Thought
从「业余时间挤一篇」到「随手一句话就发一篇」——这不是夸张，是我过去 5 个月的真实经历。
2013 年我写了 43 篇博客，之后的 12 年里年均不到 5 篇。2026 年才过了 5 个月，已经发了 127 篇。月产量从 2 篇跳到 25 篇，12 倍。这篇文章不是讲 AI 写作工具多好用，而是讲我如何把 整个写作流程 编码成了一个 Agent 可执行的 Skill——一个会自己写博客的系统。
AI 原生周报：从「周五补作业」到「数据自然长出来」
AI-Native Weekly Report — From Friday Homework to Organic Data Aggregation
每个周五下午，你的团队在做同一件事：打开空白文档，回忆这周干了什么，凑出一份周报。
这件事的荒谬之处在于——周一到周五，你们已经开了 10 次站会，讨论了 50 个问题，做了 20 个决策。所有信息都已经存在了，只是散落在会议录音、聊天记录、任务系统里。周报不是「写」出来的，应该是「长」出来的。
这篇文章用一个 War Room Scrum 的完整案例，说明怎么用 AI 原生思维重构日报和周报流程。核心转变： 不是让 AI 帮你润色周报，而是让 AI 从日常运转的数据中自动聚合出周报。
[Read More]