Vibe Coding Production Kit:给 AI 编码智能体套上生产级工作流
Vibe Coding Production Kit(VCP)发布,这是一个零运行时依赖的 CLI,把 AI 辅助开发组织成规范、架构、有界任务、就绪门禁、验证证据和独立评审组成的工程生命周期,支持 Codex、Claude Code、Cursor、GitHub Copilot 等工具。
Awaiting translation
Vibe Coding Production Kit(VCP)发布,这是一个零运行时依赖的 CLI,把 AI 辅助开发组织成规范、架构、有界任务、就绪门禁、验证证据和独立评审组成的工程生命周期,支持 Codex、Claude Code、Cursor、GitHub Copilot 等工具。
Awaiting translation
一份 AGENTS.md 文件要求 AI 智能体不要盲从用户指令,因为用户可能对代码库、语言、架构和工具了解有限,现有代码也可能出错或过时。它要求智能体改代码前先检查仓库、通过代码和测试验证假设,优先采用简单稳健的方案,用户方案不佳时直接替换,并且绝不伪造成功,尽可能运行构建、测试和 lint。
Awaiting translation
适配器模式的价值在于把外部供应商 API 翻译成应用自身理解的接口,避免供应商决策渗透整个产品,是商业杠杆而非整洁代码装饰。作者指出,让 AI 编程智能体"使用设计模式"多半只是空想,它能生成形似适配器的代码,却难以自行判断边界是否必要、测试该保护哪些行为、哪些取舍仍需人来做决定。作者附上一个 Ruby 供应商边界示例,展示适配器如何翻译供应商 API 并把接线留在核心调用代码之外。
Awaiting translation
针对 AI 编程智能体指令文件中常见的“写整洁代码”“用 TDD”“遵循 SOLID”等表述,作者指出这些说法本身没错,但都不是可自我执行的指令。智能体主要复用代码库中已有的模式,在好坏混杂的真实代码库里,这类指令只是表达愿望。作者主张改为展示好与坏的具体样例,并让智能体证明自己实际遵循了哪些模式、在哪里应用、如何验证结果。
Awaiting translation
有用户在 Cursor Forum 分享为 Cursor 设置 VHDL 规则的经验:Cursor 写 VHDL 时会在 entity 内使用 output signal,并会从多个 process 驱动同一信号。
Awaiting translation
作者结合 18 个月构建智能体系统的经历提出,AI 原生设计应先问“这块能不能删掉”,而不是“能不能加上 AI”,并称自己的技术栈随模型变强缩减了 60-70%。
Awaiting translation
Drew Breunig 整理出 agentic coding 的 10 条经验,面向刚上手 Codex、Claude Code、Pi 等智能体的人。他主张代码变便宜后应通过实现来学习、频繁重建,把投入放在端到端测试、记录意图和保持 spec 同步上,并自动化简单工作、把精力留给设计、性能、安全等难的部分。他强调代码便宜但维护、支持和安全并不便宜,智能体也会放大开发者已有的经验与品味。
Awaiting translation
作者认为自定义指令文件只应放智能体无法自行推断的仓库事实,包括仓库地图、改动范围规则、验证命令、最终回答格式和禁止的捷径,而不应放人格设定、政策口号或一次性任务细节。
Awaiting translation
AI Hero 的 skills 仓库更新,把 /ubiquitous-language 废弃并合并进新 Skill /grill-with-docs,输出从 ubiquitous-language.md 改为 context.md,并支持多个限界上下文各自维护共享语言。
Awaiting translation
Why it matters: 作者把 /ubiquitous-language 合并为 /grill-with-docs,并给出 ADR 触发条件与多限界上下文做法,可迁移到自己的 Skill 配置。
Lovable 针对 CTO 和 CIO 采用 AI 开发工具前最常见的五类顾虑给出回应:影子 IT、厂商评估疲劳、需求与实现之间的落差等。Lovable 称其编辑、审批、发布为独立的服务端权限,发布需显式授权,代码可导出为 React、TypeScript、Tailwind CSS 并同步至 GitHub,且客户提示词、代码与工作区数据不用于训练模型。
Awaiting translation
Ryan Lopopolo 以 Symphony 为例提出,代码不应被视为最终产物,规范才是分发物。Symphony 是一个基于 issue tracker 的智能体编排系统,先以 SPEC.md 形式分发,Elixir 参考实现只是衍生产物,README 邀请读者把 SPEC.md 交给自己的编码智能体,用任意语言重建。
Awaiting translation
Why it matters: 作者用 Symphony 的 spec 蒸馏循环说明代码只是可替换产物,为规范驱动开发提供了一条可迁移的路径。
Lovable 的 Workspace Knowledge 允许管理员定义持久化指令,自动应用到工作区内的每个项目,覆盖编码规范、测试要求、库偏好和架构边界。官方给出 9 种用法,包括强制 TypeScript strict 模式、统一使用 shadcn/ui、Zustand、Zod 与 Tailwind CSS,并默认执行 Bun 前端测试、Deno 后端测试和浏览器端到端验证。
Awaiting translation
Drew Breunig 在 MLOps Community 的 Coding Agents 会议上分享了他构建无代码库 whenwords 的经验,并提出规范驱动开发不是单向方程而是三角反馈循环:写代码会反过来改进规范和测试。
Awaiting translation
作者用 Codex 重写博客构建,目标是不做客户端渲染、免费托管在 GitHub Pages 的前提下实现 Vite 原生渲染、MDX 文章与静态 dist 输出。
Awaiting translation