AI 精选动态
智能评分 60
前 Meta/微软/Atlassian 主任工程师的 Agentic 工程工作流
AI 推荐理由
该工作流提出反直觉的‘不审 diff’策略和 token 高效原则，与主流 Agent 实践差异显著，值得详细阅读原文或观看视频以评估可复现性。核心解读
前 Meta/Microsoft/Atlassian 主任工程师 Kun Chen 分享了一套 Agentic 工程工作流，声称每天能交付 40-50 个经测试的生产级 PR。工作流包括全终端环境（WezTerm+tmux+Neovim）、精简的 27 行全局 memory、从记忆分离的 skills 机制、语音输入（OpenSuperWhisper）、AXI 工具设计标准（指出 MCP server 比 CLI 多耗 3 倍 token 与 2 倍延迟）、交互式规划工具 Lavish、以及自动化验证流水线（no-mistakes）。还提到 Karpathy 的 skills 仓库（17.7 万 star）经评测后使用反而多耗 5% token 且结果更差，并警告流行 skills 的安全风险。
全文
前 Meta/Microsoft/Atlassian 主任工程师的 Agentic 工程工作流
用这套工作流 @kunchenguid 每天 ship 40-50 个经测试的生产级 PR，他这么形容它：「你是船长，agent 是你的船员，分四层递进: 造船 → 训练船员 → 与单个船员协作 → 并行指挥多个船员 + 一位大副」。
https://t.co/uno8aZl0EP
# 终端中心主义(造船)
坚持全终端工作，核心理由：
· 手不离键盘 = 维持心流,鼠标切换会强制上下文切换
· 跨设备一致性——同一套工作流可在手机/不同机器上接续
工具栈：WezTerm (跨平台、Lua 配置、热重载) + tmux (会话持久化、多 pane、可远程 attach) + Neovim (键盘优先、相对行号)。
# 船员的入职培训(Memory + Skills)
agent 是新兵，不知道你的偏好。两类机制 ramp up：Memory 和 Skills
1. Memory
· 全局 memory(如 ~/.claude/CLAUDE.md)：保持精简(27 行)，因为内容会注入每次会话的系统提示词，过长会"静默"消耗 token
· 几条有洞察的偏好规则：
1. 不要用 em-dash(—)——AI 默认会用，显得机械
2. 做技术决策时不要高估开发成本——模型用人类数据训练，会高估耗时(预估"天/周",实际几分钟出可玩版本)，这种偏差会让模型偏向"便宜但低质量"方案。这条是纠正模型训练偏差
3. bug 修复优先端到端复现，而非依赖单元测试
· 项目级 memory：核心方法不是手写，而是每次纠正 agent 后让它把教训写进去——项目集体学习的沉淀
2. Skills
· 把条件性内容(如仅改代码时才需要的 E2E 说明)从 memory 抽到 skill
· skill 启动时只加载简短描述，用到才读全文——避免无谓 token 消耗
3. 关于 skills 的重要警告
· Karpathy 的 skills 仓库(17.7 万 star)经 program-bench 评测后，使用反而多耗 5% token 且结果更差，且并非 Karpathy 本人所写
· 安全风险：skill 可在机器上执行任意命令，可能泄露 API key 甚至银行凭证
· 结论：流行 ≠ 优质。不要装声称"神奇提升"却无严格评测的 skill
# 与单个船员协作
1. 语音输入
· 几乎全用语音替代打字(Stanford 论文：说话比打字快 3 倍)
· 工具 OpenSuperWhisper：本地 whisper，免费开源，通过 system prompt 注入自定义词汇表提升专有名词识别
2. AXI 标准 (Agent ergonomics)
自创的为 agent 优化工具的设计标准：
· 实测：同样 GitHub 任务，MCP server 比 CLI 多耗 3 倍 token + 2 倍延迟
· 设计原则之一：token 高效输出格式比 JSON 节省 ~40% token
· 启示：给 agent 的工具本身的效率，直接决定 agent 的"油耗"
3. Lavish (交互式规划工件)
针对"agent 返回一堵文字墙难以评审"的痛点：让 agent 生成 HTML 可视化工件，复用项目设计系统，可针对具体元素批注反馈并在浏览器内回传。
# 验证：no-mistakes 流水线(质量基石)
反直觉主张：不要逐个 review diff。
· 理由：AI 写代码太快，逐 diff 审查会让人成为瓶颈且无趣
· 类比：像工程总监一样思考——总监不审 PR，而是通过文化和流程把控质量
流水线在隔离 worktree 中执行:
· 分析会话还原真实意图
· rebase 到最新 main，提前解决冲突
· 对抗式 review(独立上下文窗口)——多数问题在此被捕获自愈，模糊的升级人类
· E2E 测试并录制证据(截图/视频/日志)
· 文档更新 + 链接检查
· 推分支开 PR，持续 babysit 直到合并
PR 呈现：原始意图、变更摘要、测试证据、流水线发现并修复的问题、风险评估。
评审策略：看风险评估决定投入精力。低风险几乎不看 diff(因流水线已覆盖)，只对高风险深入。
工作分布洞察：时间花在任务开头(用 Lavish 澄清需求)和结尾(把质量关)，中间全交给 AI。中间腾出越多，并行越多。
# 长时间运行：good-night-have-fun
解决"睡觉 8 小时如何让 agent 持续干活"：给目标和停止条件，在循环中迭代。
相比 Claude Code/Codex 的 /go，优势是可精确设置 token 上限 / 迭代上限 / 停止条件——避免睡醒发现周配额耗尽。
# 并行：treehouse + worktree
git worktree 的痛点：起名、记状态、手动清理 = 认知债。treehouse：运行即落入空闲 worktree，关闭 tab 自动释放，treehouse status 一目了然。
# First Mate：大副编排器
并行会话变多后，上下文切换疲惫。
First Mate 是元 agent，替你管理所有船员：你只跟它对话,它自动拆并行子任务、调用 treehouse 建 worktree、跑 no-mistakes、准备 PR。
关键观察：用了 First Mate 后，瓶颈从"agent 执行力"转移到"你想让它做什么"——船长的价值转向战略：理解用户、研究竞争、画好"藏宝图"。
> **引用原帖 Kun Chen (@kunchenguid):**
> many people asked me to make a video about my complete agentic engineering workflow
> excited to share it's finally here!!!
> it took me about 20 hours in total to record this 45 minutes of walkthrough - it covers everything i do to ship production quality code at an average 40+ PRs/day velocity
> hope this can be a useful reference to everyone exploring good ways to use AI. and would appreciate a reshare with anyone you think might benefit from this!
> enjoy! https://t.co/oA0UCrBvqo
> https://x.com/kunchenguid/status/2068367773533667565