agent-skills 发布 implement-spec:把 spec 端到端跑成可验证 PR 的 Agent Skill
SteveVitali 发布 agent-skills,一套与 harness 无关的 Agent Skills,旗舰 Skill implement-spec 接收 agent-ready spec 后自主完成分支、计划与测试矩阵、实现、两轮自审、与 spec 的差距分析、补齐、实时验证,最后产出 PR 和验收标准证据报告。
SteveVitali 发布 agent-skills,一套与 harness 无关的 Agent Skills,旗舰 Skill implement-spec 接收 agent-ready spec 后自主完成分支、计划与测试矩阵、实现、两轮自审、与 spec 的差距分析、补齐、实时验证,最后产出 PR 和验收标准证据报告。
作者认为 AI 代码评审适合作为 diff 的快速第一遍检查,能发现空值解引用、边界错误、注入、权限校验缺失、重复事件和缺少迁移等局部问题,但无法判断需求意图、跨系统行为、架构成本和用户影响。
anyaa-labs 在 GitHub 发布 agent-architect Skill,支持 Claude Code 和 Codex,用于评估和设计多智能体系统。
作者发布 Bullshit Detector,一套可移植的 Agent Skills,把 YouTube、TikTok、文章、推文或 PDF 拆成逐条声明,联网核查后给出确认、存疑、误导、错误、无法核实五类判定和 0–10 的 BS 分数,并附来源链接。
作者用 Cursor 和 Claude Code 实际发布过多个产品,把 AI 建应用拆成八个阶段,指出智能体擅长搭脚手架、写界面和生成 CRUD,但选技术栈、判断界面是否正确、防止脏数据、真机测试、域名 DNS 密钥和线上排错仍要人来做。
Geoffrey Huntley 宣布加入 Antithesis,主张用形式化验证和确定性系统测试应对 AI 时代代码量激增带来的审查危机。他认为软件编写已被商品化,但验证与理解仍非免费,Antithesis 结合 LLM 对抗式代码审查与 pre-commit hook 驱动的语言分析器,可让人类和智能体交付可靠软件而无需掌握专门知识。
Augment Code 提出循环工程,即设计从触发、执行、验证到完成结果的智能体循环,让智能体承担中间环节、人类只在需要判断的检查点介入。文章把循环工程与提示词工程、上下文工程分层对比,并给出触发、执行、验证、结果、改进五个阶段,以及代码评审、工单转 PR、漏洞修复、事故响应四种已在生产运行的团队级循环。
推荐理由:Augment Code 把循环工程拆成触发、执行、验证、结果、改进五阶段,并给出四种已在生产运行的团队级循环形态。
AI 编程基准只衡量模型能否在限定条件下完成改动,却测不出它留下的代码库是否更难维护——重复逻辑、耦合收紧、多余抽象都不会让当前测试失败,代价在后续扩展或排查线上问题时才显现。作者主张把可维护性放进交付流程:仓库级规范、清晰的架构边界、有意义的测试与静态分析,并审查重复、复杂度、架构漂移和模式不一致。
作者指出 eslint-plugin-playwright 的 recommended 配置里 no-wait-for-timeout、no-force-option、expect-expect 等关键规则只是 warning,不设 --max-warnings 0 就不会拦住合并,而 floating promise 等缺陷在没装插件时完全不可见。
Addy Osmani 提出软件工厂由 loop、harness、factory 三层构成,工厂不是更聪明的智能体,而是多个带 harness 的 loop 汇入一个评审门禁、由人掌控外层循环。
推荐理由:作者把软件工厂拆成 loop、harness、factory 三层,并指出验证而非生成才是真正的瓶颈。
当前 AI 智能体演示普遍在无限 token 预算、全新或精选代码库、无合规与运维压力的条件下运行,展示的是能力上限而非真实交付环境。AWS 副总裁 Marc Brooker 指出,智能体的机会受限于缺陷率,开发者调研中已有团队称其 AI 工具预算不可持续。作者建议只给智能体与验证能力和预算相匹配的自主权,用标准、检查项和可追踪的支出逐步放宽。
作者以自己用 AI 构建并上线的 Apatero 和 Tool Index 两个产品为例,说明 AI 能在一小时内搭出可点击的演示,但真正上线还要处理托管、鉴权和支付。
作者评审了一个 Agent 提交的 Pull Request,认为它又快又好,原因不在模型有多聪明,而在于质量门槛被写进了循环内部。这个 PR 在请求人工介入前就说明了改动了什么、刻意没动什么、该重点审查哪里、遵循了哪些规范,并附上了已运行的验证证据。作者由此提出,给 Agent 一个明确的完成定义和必须自证的标准,它就会为通过标准而优化,速度不是靠降低门槛换来的。
Addy Osmani 在 AI Engineer World's Fair 2026 闭幕演讲中提出,智能体负责内循环(调查、实现、验证、重复),工程师要负责外循环,即对系统结果的可问责性。
作者 jbwinters 发布 Jacquard,一门面向 AI 编写、人类审查的编程语言,设计方式是让 AI 分析多种主流及小众语言的 AST 后生成新的结构与语法。
一位 QA 工程师把半年在 Claude Code 上做 Web 测试的经验整理成开源 Skill 包 paranoid-qa,核心是一份证据契约:Pass/Fail 只能依据截图、请求体、日志等实际产物,未验证写 Not tested,环境受阻写 Blocked,表单必须检查真实提交 payload。
推荐理由:作者把半年 QA 经验固化成 Claude Code 的测试 Skill 包,并给出可直接复用的证据契约与失败清单。
一些团队开始让 AI 智能体在 CI 全绿后自动合并自己提交的 PR,不再有人工介入。但绿色检查之所以能作为合并信号,靠的是检查运行前人类对意图、测试保护范围和系统风险点的判断,CI 只是确认而非替代这一判断。作者认为自动合并只适合低风险、边界清晰且有历史记录的改动,信任需要靠一次次带证据的改动积累,而不是打开一个开关。
AI Hero 的 skills 仓库发布 v1.1,把 /to-prd 重命名为 /to-spec,将 /to-plan 和 /to-issues 合并为 /to-tickets,并新增 /wayfinder、/research、/prototype 等 Skill。
推荐理由:作者把 grilling 到部署的完整 Skill 流程讲清楚,并给出重命名、合并和新增 /wayfinder 的迁移命令,适合想搭 AI 开发工作流的人参考。
作者认为测试只是抽样,形式化验证才能给出证明或反例,而 AI 智能体正好补上了形式化方法最贵的三块:写规格、解析反例、反复迭代。他给出 Z3、Dafny、TLA+、Alloy、Infer、Certora、Lean/Coq 的适用场景与安装方式,并指出验证器 CLI 可以像普通工具调用一样接入智能体循环,但规格写错、抽象层差异和状态空间爆炸仍是主要成本。
一份面向 AI 工程岗位的面试题追问清单,覆盖代理网关(如 OpenRouter/LiteLLM)、MCP/CLI、从零手写 Agent、多智能体编码流程、自定义 benchmark 以及本地部署约 27B-Q3_K_M.gguf 模型等方向。作者认为,这些题目的通用版本如今谁都能靠 vibe coding 一晚做出来,已失去简历价值,真正稀缺的是把任务打磨到"理想"状态的能力。
针对 AI 编程智能体指令文件中常见的“写整洁代码”“用 TDD”“遵循 SOLID”等表述,作者指出这些说法本身没错,但都不是可自我执行的指令。智能体主要复用代码库中已有的模式,在好坏混杂的真实代码库里,这类指令只是表达愿望。作者主张改为展示好与坏的具体样例,并让智能体证明自己实际遵循了哪些模式、在哪里应用、如何验证结果。
Drew Breunig 提出提示词债概念,认为用自然语言手写提示词来定义系统行为会带来三重后果:迭代变慢、团队难以读懂、应用被锁死在单一模型上。他引用 Datadog 报告称其观测到的流量中最常用的模型是 GPT-4o,并举例 Fable 的系统提示词把同一条版权规则重复了六次、Claude Code 让 Opus 七次要求在一次响应中返回多个工具调用。
Greptile 工程师 Shlok 介绍新代码评审器 TREX(Test, Run, Execute),它在评审 PR 之外真正运行代码,把截图、日志、API trace 和执行脚本作为证据附在每条发现上,发现 bug 就发成 PR 评论。
Superpowers 6 发布,作者称在 Anthropic 评测基准上构建耗时降低 50%、token 花费降低 60%,主要来自合并规范符合性与代码质量两个评审 agent、预先生成评审用的 diff 包让评审者少跑 git,以及调整编排器对任务所需 agent 类型的指引。
推荐理由:作者用自建评测套件量化了 Superpowers 6 在构建耗时和 token 花费上的改进,并公开了实验记录与失败结论。
作者结合 18 个月构建智能体系统的经历提出,AI 原生设计应先问“这块能不能删掉”,而不是“能不能加上 AI”,并称自己的技术栈随模型变强缩减了 60-70%。
面对 AI 编程智能体带来的提速压力,作者认为更快的代码生成不等于更快的软件交付,意图、验收标准、风险边界、验证、证据与评审等交付纪律不可让步。智能体只有在既有工作流内运作才能参与其中,工作越交给智能体,可评审性就越重要。这是 Software Dark Factory 背后的核心理念:智能体应强化而非取代经过验证的交付实践。
Learn Harness Engineering 是一门专注 AI 编程智能体工程的课程,综合了 OpenAI 关于在 agent-first 世界中使用 Codex 的 harness engineering 实践,以及 Anthropic 关于长时运行智能体 harness 设计与应用开发的两篇文章。
作者认为 AI Skill 采用率停在低位的原因不是培训不足,而是缺少能持续证明其在未测试场景下有效的评测框架。他建议从 10–15 名工程师访谈和生产日志构建 50–100 条用例集,用精确匹配和 LLM-as-judge 两种方式打分,并每季度人工标注 50 条校准裁判模型。
越来越多工程团队在讨论让 AI 智能体自动合并 PR,但真正的信任问题不在模型本身,而在于变更意图是否明确可审、验收标准是否事先定义、风险边界是否划定、验证是否真正执行、智能体权限是否受限,以及是否有可审查的决策记录。缺少这些,自动合并只是让决策变快,而非交付变快。Software Dark Factory 正尝试把意图、标准、约束、验证和权限边界内建到工作流中,让治理先于速度。
作者认为编码智能体的 harness 是模型外的软件层,负责组装上下文、暴露工具、控制运行循环、执行权限并评估结果,因此同一模型在不同 harness 下表现会完全不同。
作者主张不要用一个大请求驱动编码智能体,而是拆成三类任务:只读不改的调研任务、限定在指定文件范围内的实现任务、独立检查结果的验证任务,每类产出不同证据,混在一起会让输出难以评审。
作者指出用 stripe_subscription_id.present? 判断用户能否访问,是把支付状态和访问权限当成同一件事,随着免费试用、宽限期、合作方访问、管理员授权等场景出现,can_access?
作者结合自己一年部署 Claude Code 和自建智能体的经历提出,智能体失败几乎不是模型能力问题,而是模型权重之外的运行环境缺陷,即 harness engineering。
Drew Breunig 整理出 agentic coding 的 10 条经验,面向刚上手 Codex、Claude Code、Pi 等智能体的人。他主张代码变便宜后应通过实现来学习、频繁重建,把投入放在端到端测试、记录意图和保持 spec 同步上,并自动化简单工作、把精力留给设计、性能、安全等难的部分。他强调代码便宜但维护、支持和安全并不便宜,智能体也会放大开发者已有的经验与品味。
作者提出可评审的编码智能体工作流应包含五个阶段:说明意图、提供仓库上下文、明确智能体可改动的边界、运行验证、要求以风险为重点的总结,跳过任一阶段只会把成本转移到评审环节。
作者 Aldrin 认为 vibe coding 适合用自然语言做低成本探索,比如脚手架、陌生 API、UI 变体和测试思路,但快速可见的草稿不等于功能可以被团队接手。
宝玉点评《Why Your "AI-First" Strategy Is Probably Wrong》一文,认为这套打法本质是软件工程问题,AI 时代人成了瓶颈。
UC San Diego 研究团队通过 13 场实地观察和 99 名资深开发者的问卷(共 112 人,中位经验 10 年,使用 Claude Code、Cursor、GitHub Copilot、Windsurf)发现,专业开发者并不 vibe coding,而是通过规划和监督严格控制智能体。
Terminal-Bench 发布任务设计指南,提出好的基准任务应具备对抗性、难度和可读性:指令像给资深工程师那样清晰直接,测试只验证结果而非实现细节,允许替代解法并防止 reward hacking。难度应来自问题本身,而非苛刻的输出格式或隐藏假设。作者建议亲自运行任务、检查容器、执行 oracle 并观察真实智能体轨迹,失败运行尤其能揭示任务是否真正困难。
作者认为,软件组织一直把人的实现时间当作稀缺投入,智能体打破了这个假设,因此策略必须可执行、验证必须随实现规模扩展。他以在大型 TypeScript 代码库开启 ESLint 的 no-await-in-loop 规则为例,发现 600 处违规,过去这需要昂贵的迁移,现在一个 PR 就能完成修复并补齐测试覆盖。
推荐理由:作者以开启 ESLint 规则、迁移 600 处违规的亲身实践,说明智能体时代实现成本下降后,约束与验证为何成为新的稀缺环节。