Harness Engineering 现在还处在很早期的阶段。软件工程发展了几十年,有成熟的方法论、教科书、最佳实践,新人进场基本都是站在前人踩过的坑上往前走。Harness Engineering 完全不是这样,现在能参考的经验少,能抄的作业也少,大部分东西都得自己摸索。 但早期恰恰是它的价值所在。一个领域一旦成熟,规则和最佳实践都定型了,新人进去更多是学习和执行,很难再抢到认知红利。而在早期，谁先动手实践、先踩坑、先总结出一套自己的方法论,谁就更有可能把这些经验沉淀成后来者绕不开的参考。 这个阶段最重要的不是等一套完善的方法论出现了再学，而是主动进场，一边做一边总结，把自己变成正在定义这套方法论的人之一。

Loop Engineering 最稳的上线方式不是一步到位无人值守。 而是分 3 层放权： L1：只报告 每天扫 CI、issue、PR，输出摘要，不改任何东西。 L2：小修复 只处理 lint、文档、测试快照这类低风险任务，必须开 PR。 L3：有限自动化 只在明确白名单里自动处理，遇到权限、支付、数据库、生产配置立刻停。 先让它看，再让它动，最后才考虑自动合并。

Loop Engineering 最容易被误解成： 让 Agent 一直自动跑。 它真正重要的地方，是目标定义。 以前你写 Prompt，是告诉 AI 这一次怎么做。 现在你设计 Loop，是告诉 AI： 什么算完成。 怎么验证完成。 失败了怎么办。 哪些动作禁止做。 什么时候必须停下来。 这要求的是管理能力。

爆肝整理，Graph Engineering 完整五步教程 👇👇 Loop Engineering 的继任者，把单线循环升级成并行图网络，一个窗口跑 1000+ Agent。 1：核心认知 单循环只能优化一个指标，容易掉进 Goodhart 陷阱。 Graph = 节点（一个Agent干一件事）+ 边（节点之间的数据依赖）。 把"先A再B"改成"A和B能并行就并行"，宽度决定速度。 2：找到真正的边 每次写"然后"时问自己：下一步真的需要上一步的输出吗？ 不需要 → 砍掉等待，直接并行。 你的"顺序执行"脚本，本质上就是个最寒酸的图——链式结构，一卡全卡。 3：上手实战 前置：Claude Code v2.1.154+，Pro/Team/Enterprise 开动态工作流。 粘贴一个prompt："审计 src/routes/ 下所有路由文件的权限校验，每个文件开一个Agent，分别验证，最多20个文件。" Claude 自动生成编排脚本，确认后跑起来。一个命令 → 十几个Agent并行 → 一份汇总报告。 中间结果存在脚本变量里，不污染你的会话上下文。 4：两个最容易翻车的地方： ① 图自说自话：让Agent检查自己的工作，它永远给自己高分。必须用独立节点验证，带独立上下文，检查真实信号（比如测试是否真的跑了）。 ② Agent互相踩脚：两个Agent同时写同一个文件=灾难。每个Agent必须有自己的隔离工作区（git worktree），结果合并策略提前定好。 5：六个可以直接套的图结构 - 安全扫描：每个文件一个Agent + 独立验证节点 - 深度研究：拆成多个角度并行搜索，Agent之间互相反驳再汇总 - 模块迁移：逐个文件迁移，测试做门禁 - 对抗性代码审查：小改动一票过，大改动全并行审计 - 定时生态扫描：存成模板，定时重跑 - 未知规模发现：并行探索，两轮没新东西就停 6：让图保持诚实 图本身不保证真相。必须锚定不可争辩的节点： - 真正跑过的测试（不是"应该能过"） - 基于证据的验证器 - Agent永远不能改的冻结规则 感谢 @0xCodila 的完整教程。

再次推荐 Google Engineering & DevRel Leader @addyosmani 重磅开源的 Agent Skills (69.7✨)，把资深工程师的生产级工程纪律，固化为 AI Agent 可机械执行、强制验证、跨工具复用的工作流 Agent Skills: Production-grade engineering skills for AI coding agents. 它要解决什么问题？ AI Coding Agent 的默认行为是"走最短路径"——跳过规格、跳过测试、跳过安全评审，给出能跑但不可靠的代码。Agent Skills 的立论是：质量不靠提醒出来的，要靠强制流程托底的。它把"什么时候写规格、测什么、怎么评审、何时发布"这类隐性工程判断，固化成 Agent 必须遵循的步骤。 顶层架构：六阶段生命周期 DEFINE → PLAN → BUILD → VERIFY → REVIEW → SHIP /spec /plan /build /test /review /ship 8 个 slash 命令作为入口，分别对应一个阶段，自动激活对应 Skills。Skills 也会按上下文自动触发（写 API → api-and-interface-design，写 UI → frontend-ui-engineering）。/build auto 在一次批准后自动跑完计划与实现，但每个任务仍独立测试、独立提交、遇险即停。 24 个 Skills 的分布 1. Meta - 1 个 using-agent-skills（路由，决定该用哪个技能） 2. Define - 3 个 interview-me、idea-refine、spec-driven-development 3. Plan - 1 个 planning-and-task-breakdown 4. Build - 7 个 incremental-implementation、test-driven-development、context-engineering、source-driven-development、doubt-driven-development、frontend-ui-engineering、api-and-interface-design 5. Verify - 2 个 browser-testing-with-devtools、debugging-and-error-recovery 6. Review - 4 个 code-review-and-quality、code-simplification、security-and-hardening、performance-optimization 7. Ship - 6 个 git-workflow-and-versioning、ci-cd-and-automation、deprecation-and-migration、documentation-and-adrs、observability-and-instrumentation、shipping-and-launch 几个值得点名的设计取向 · doubt-driven-development：对抗性"新上下文复盘"，CLAIM → EXTRACT → DOUBT → RECONCILE → STOP，可选跨模型升级。这是该仓库比较有原创性的一项，针对高代价/不可逆决策。 · source-driven-development：框架决策必须挂在官方文档上，要引源、要标注未验证项。直接对治 LLM 编造 API。 · deprecation-and-migration 把"代码即负债"单列为技能，配套强制 vs 建议性弃用模式与僵尸代码清除——很少见但有工程味。 · Google 工程文化底蕴：Hyrum's Law（API）、Beyonce Rule 与测试金字塔（测试）、变更尺寸约 100 行 + 评审速度规范（评审）、Chesterton's Fence（简化）、主干开发（git）、Shift Left 与 feature flag（CI/CD）。来源明确标注自《Software Engineering at Google》与 Google 工程实践指南。