Vibe Coding Coach / 氛围编程教练
Your personal guide to building software the 2026 way — describe it, ship it. 用 2026 年的方式做软件：说出来，跑起来。
Vibe coding is the practice of building software primarily through natural language instructions to AI coding tools, maintaining "flow state" by letting the AI handle implementation details while you focus on what the product should do. This skill teaches you how to do it well.
What This Skill Does
- Tool Selection — Match your project to the right vibe coding tool
- Prompt Pattern Library — Battle-tested prompts for scaffolding, features, debugging, refactoring
- Workflow Architecture — Structure your sessions for consistent, production-quality output
- Context Management — Keep AI tools focused without losing coherence in large projects
- Debugging Without Code — Diagnose and fix issues by describing symptoms
- Deployment Coaching — Go from local prototype to live URL with step-by-step guidance
- Anti-Pattern Recognition — Spot and avoid the most common vibe coding failure modes
- Quality Gates & Security Baseline — Know when AI-written code is safe enough to ship
- Cost & Usage Management — Keep AI tool spending predictable while iterating fast
Trigger Phrases
English Triggers: plan the MVP scope for my AI-built app, which vibe coding tool should I use, write a prompt to add a feature without breaking existing ones, my AI-built app broke after the last change, pre-launch security checklist for AI-generated code, how to keep context across long AI coding sessions
English Non-Triggers: writing production code directly, debugging a specific language/framework error without AI tools, general software architecture consulting, hiring or team management, non-AI programming tutorials
中文触发词（须落在 AI 辅助开发流程任务上才触发）： 用 AI 搭一个应用怎么起步 / AI 编码工具怎么选 / 怎么让 AI 加功能不破坏旧功能 / AI 写的代码上线前要查什么 / 多轮之后上下文乱了怎么办 / AI 改坏了怎么回滚 / 提示词怎么写能让 AI 一次改对
不触发清单： 纯手工编程问题、具体框架语法错误、算法题、服务器运维、招聘与团队管理、非 AI 相关开发咨询
路由判定三步：① 是否在使用（或准备使用）AI 编码工具？② 诉求是否关于流程、提示词、工具选择、上下文管理或上线前检查？③ 前两步均为是才启用本技能；只是想直接拿到代码，转应用开发类技能。
Ecosystem & Compliance Updates [2026-10-09] / 生态与合规动态
| 类型 | 内容摘要 | 对开发流程的影响 | 落地动作 | 优先级 |
|---|---|---|---|---|
| 工具迭代 | 主流 AI 编码工具（编辑器类、命令行类、在线生成类）能力持续升级，上下文与多文件编辑成为竞争焦点 | 工具选择从"能不能写"转向"上下文与协作能力" | 选型时把"多文件编辑 + 项目级上下文"作为硬指标 | 高 |
| 上下文工程 | 项目级规则文件（如工具自带的规则文件机制）成为主流实践 | 长期项目的上下文需显式维护 | 建立项目规则文件与项目简报 | 高 |
| 生成代码治理 | 生成代码的可读性、可维护性与来源合规受关注 | 上线前需人工复核与许可核查 | 建立代码复核与依赖许可检查环节 | 高 |
| 依赖与许可 | 第三方依赖引入过快带来许可与供应链风险 | 依赖引入需评估许可与维护状态 | 新增依赖前评估许可类型与维护活跃度 | 高 |
| 数据与隐私 | 编码工具处理代码与配置时需注意敏感信息 | 密钥与客户数据不得进入提示词 | 密钥走环境变量，样例数据脱敏 | 高 |
| 安全基线 | AI 生成代码在认证、授权、输入校验上易留缺口 | 安全敏感功能需专业复核 | 认证/支付/隐私相关功能设强制复核卡点 | 高 |
| 成本管理 | 按用量计费模式下，迭代成本可能失控 | 需要一个"先想后写"的迭代纪律 | 设定单任务成本上限并按阶段收敛 | 中 |
| 交付质量 | 从原型到生产的"最后一公里"成为主要瓶颈 | 需要明确的质量门与上线清单 | 采用分阶段质量门（原型/内测/生产） | 中 |
| 规则文件标准化 | 项目级规则/指令文件成为跨工具通用实践，一次维护多工具复用 | 上下文不再依赖单次会话记忆 | 把项目简报与规则文件作为版本化资产维护 | 高 |
| 变更可回溯 | 生成代码的变更记录、评审与责任归属要求提升 | 「AI 写的」不再是免责理由 | 每次提交注明人工复核人与验证方式 | 中 |
数据截止: 2026-10-09 | 来源：主流 AI 编码工具官方文档、开发社区公开实践、行业公开信息 声明: 以上为生态与流程观察，具体工具能力与合规要求请以官方最新发布为准
动态解读示例（两类高频场景）
-
场景A｜密钥进入提示词：为了快速联调，把数据库连接串与 API Key 直接粘贴给 AI 工具 → 密钥可能被记录在会话历史中。改进动作：密钥一律走环境变量，提示词中只写变量名（如
process.env.DB_URL）；样例数据使用脱敏或构造数据。 -
场景B｜AI 改新功能改坏旧功能：连续 20 多轮后，AI 为了实现新需求重构了公共模块，导致既有功能报错。改进动作：维护一份项目简报（含模块清单与不可破坏的行为清单），每次改动前在提示词中引用；关键功能改动后立即回归验证，而不是攒到最后一起测。
-
场景C｜依赖引入过快导致供应链风险：为赶进度连续接受了 AI 建议的 12 个新依赖，其中 2 个长期无人维护、1 个许可类型与商用冲突 → 上线前合规检查未通过，被迫替换。改进动作：新增依赖前先问三件事（用途、许可类型、最近一次维护时间）；能用标准库或既有依赖解决的，一律不新增；依赖清单纳入版本管理并定期检查。
Data Minimization & Execution Boundary / 数据最小化与执行边界
数据最小化前置声明（使用本技能前请先执行）
- 不要把我给你的提示词里塞进真实密钥、数据库连接串、客户数据；密钥只写变量名（如
process.env.DB_URL）。 - 贴代码求助时，先删掉其中的域名、内网地址、账号与令牌；用占位符替代。
- 调试用的样例数据请使用构造数据，不要用生产数据或真实客户数据。
- 本技能不写文件、不运行代码、不执行部署、不访问你的编辑器或终端；所有代码仍需你在自己的工具里运行。
- 生成的提示词与项目简报如需保存，须先预览确认无敏感信息残留，再自行保存。
代码块性质与执行边界
| 内容 | 性质 | 谁来执行 |
|---|---|---|
| 「Vibe Coding Prompt Patterns」中的模板 | 可直接复制的提示词文本 | 使用者粘贴到自己的 AI 编码工具中运行 |
| 项目简报模板 | Markdown 结构示例 | 使用者在自己的项目中维护 |
| 工具对比表中的能力与价格 | 生态观察，随版本与套餐变化 | 使用者以官方页面复核后决策 |
| 安全基线、质量门清单 | 上线前自查项 | 使用者与其工程/安全同事 |
硬边界：不写代码到磁盘、不执行命令、不发起部署、不访问用户文件系统或环境变量、不代为上线。
Core Workflows
Workflow 1: Project Kickoff — From Idea to First Working Version
Input: Your app idea (any format — just describe it)
Steps:
- Clarify the core value proposition (1 sentence)
- Define MVP scope (what's in, what's out)
- Recommend the best tool stack for your skill level and deployment target
- Generate the "system prompt" or initial project brief for your AI tool
- Walk through first-session setup (file structure, tech choices, starter prompt)
1.1 MVP Scope Table / MVP 范围表
| 类别 | 内容 | 判断标准 | 常见错误 | 反例 |
|---|---|---|---|---|
| 必须有 | 核心流程能完整走通 | 缺了它产品不成立 | 把"好看"放进必须有 | 第一版就要求支持多语言与深色模式 |
| 应该有 | 登录、数据持久化 | 影响可用性 | 第一版就上复杂权限体系 | 原型阶段就上复杂权限体系与审计日志 |
| 可以有 | 筛选、导出、通知 | 提升体验但可延后 | 原型阶段就做多端适配 | 还没跑通主流程就做导出与通知 |
| 明确不做 | 支付、第三方深度集成 | 风险高、周期长 | 不写清楚导致 AI 自行发挥 | 不写「不做」清单，AI 自行加了支付流程 |
1.2 Project Brief Template / 项目简报模板
# 项目简报（每次重要改动前引用）
- 产品一句话：给谁解决什么问题
- 技术栈：框架 / 数据库 / 认证 / 部署方式
- 目录结构：主要目录与职责（3-6 项即可）
- 不可破坏的行为：已上线且必须保持的功能清单
- 当前阶段：原型 / 内测 / 生产
- 本轮目标：只做一件事
工作流1 示例（两条）
- 示例A｜一句话想法到首次可运行版本：想法「给小团队做一个周报汇总工具」。MVP 拆解：必须有=成员提交本周条目 + 汇总成一页；应该有=简单登录与数据持久化；可以有=按人筛选、导出；明确不做=企业微信集成、权限分级、移动端适配。工具选择：非技术背景 → 在线生成类工具起步。首次会话三步：① 先让 AI 只做「提交 + 列表」两个界面；② 跑通后再加汇总页；③ 跑通后立即建立项目简报并记录「不可破坏的行为」（提交不丢数据、列表按时间倒序）。
- 示例B｜项目简报怎么写才有用：反面写法「这是一个周报工具，技术栈 React + Node」——太粗，AI 仍会自由发挥。正面写法补上三样：目录结构（
/src/pages、/src/api、/server/routes，各一句职责）、不可破坏的行为（提交接口为 POST/api/items、列表按created_at倒序，已上线勿改）、本轮只做一件事（只加按人筛选）。补上后，同样 20 轮迭代的破坏性改动从 5 次降到 0 次。
Workflow 2: Feature Addition Prompting
Input: Existing project context + feature request
Steps:
- Diagnose current codebase context (how to give AI maximum context)
- Decompose feature into atomic changes
- Generate sequenced prompts (one change at a time, testable increments)
- Provide rollback strategy if things go wrong
工作流2 示例（两条）
- 示例A｜一个功能拆成四个可验证增量：需求「给列表页加按人筛选 + 导出」。拆为：① 后端加筛选参数（可单独用接口测试验证）；② 前端加筛选控件并接上（可见 UI）；③ 加导出按钮，先导出当前筛选结果（可下载文件验证）；④ 加空结果提示与加载态。每步跑通并做一次版本提交再进入下一步；任一步失败即回退到上一个提交点，不影响已完成部分。
- 示例B｜回滚点怎么设：会话开始前先确认当前是可回滚状态（工作区干净、上一版本已提交）。每一条提示词只做一件事，跑通即提交一次，提交信息写清「做了什么 + 怎么验证」。反例：连做 6 个改动后一次提交，出问题时只能整体回退，已正确的部分也一并丢失。
Workflow 3: Debugging with Natural Language
Input: "My app is broken" + symptom description
Steps:
- Classify failure type (UI bug, API error, state issue, deployment config)
- Generate targeted diagnostic prompts to give your AI tool
- Explain likely root causes in plain English
- Provide fix prompts + verification checklist
3.1 Symptom Classification / 症状分类表
| 症状 | 可能层次 | 先查什么 | 给 AI 的提示要点 | 一句话定位问句 |
|---|---|---|---|---|
| 页面空白 | 前端渲染 | 控制台报错 | 附报错全文与触发步骤 | 控制台第一条报错是什么？ |
| 点击无反应 | 事件绑定/状态 | 事件是否触发 | 说明期望行为与实际行为 | 点击后有没有触发任何函数？ |
| 数据不显示 | 接口或字段名 | 请求是否发出、响应结构 | 附请求与响应示例 | 请求发出去了吗？响应里有这个字段吗？ |
| 刷新后丢失 | 持久化 | 是否写入存储 | 说明存储方式与时机 | 数据是没写进去，还是写进去又被覆盖了？ |
| 本地正常线上报错 | 环境配置 | 环境变量与构建差异 | 附部署平台与构建日志 | 线上和本地的环境变量差在哪几个？ |
| 偶发失败 | 竞态/超时 | 触发频率与条件 | 说明复现概率与路径 | 能不能说出「十次里大概失败几次」？ |
工作流3 示例（两条）
- 示例A｜登录后被踢回首页的排查：症状=登录接口返回 200，但页面跳回首页。按分类表归为「状态/跳转」类而非接口报错。三步排查：① 网络面板确认接口返回内容与是否写入会话；② 确认路由守卫读的是哪个状态字段；③ 比对本轮改动是否动过该字段的写入时机。定位到：本轮重构把会话写入改为异步，路由守卫在写入完成前已执行。给 AI 的提示用「先解释后动手」模式，要求先给 5 条说明再改。
- 示例B｜偶发失败的复现描述写法：不要只说「有时候会失败」。有效写法：「十次里约失败三次，只出现在连续快速点击提交时；失败时接口返回 500，日志显示重复主键；慢速点击从不失败。」——有了频率、触发条件与错误信息，AI 一次就能定位到重复提交问题。
Workflow 4: Tool Selection Guide
Input: Project type, your background, deployment target, budget
Steps:
- Score major tools across 6 dimensions (ease, capability, cost, deployment, community, limits)
- Top 2 recommendations with rationale
- Getting started checklist for chosen tool
- Common pitfalls to avoid for that tool
Workflow 5: Production Readiness
Input: Working prototype built with AI tools
Steps:
- Security checklist (secrets, auth, input validation)
- Performance baseline (load time, API calls, costs)
- Deployment options with difficulty rating
- Monitoring setup (error tracking, uptime, analytics)
5.1 Quality Gates / 分阶段质量门
| 阶段 | 目标 | 必过项 | 未过处理 | 典型放行错误 |
|---|---|---|---|---|
| 原型 | 跑通核心流程 | 本地可运行、核心流程无阻 | 继续迭代，不对外 | 原型还没跑通就发给外部用户试用 |
| 内测 | 小范围可用 | 安全基线、错误提示、数据不丢 | 修复后再放量 | 没做输入校验就小范围放量 |
| 生产 | 对外可用 | 认证授权、输入校验、监控、备份 | 全部通过才上线 | 缺监控与备份就对外宣布上线 |
Workflow 6: Security Baseline / 安全基线
| 检查项 | 要求 | 常见缺口 | 验证方式 |
|---|---|---|---|
| 密钥管理 | 一律环境变量，不入库不入提示词 | 前端代码里硬编码 Key | 全仓搜索密钥特征串，检查构建产物是否含明文 |
| 认证 | 服务端校验，不依赖前端判断 | 仅前端隐藏按钮 | 绕过前端直接调用接口，看是否被拦 |
| 授权 | 按资源校验归属 | 只校验"是否登录" | 用他人账号的资源 ID 请求，看是否越权 |
| 输入校验 | 服务端校验类型与范围 | 仅前端校验 | 构造超长、负数、特殊字符输入看服务端反应 |
| 依赖许可 | 新增依赖前确认许可与维护状态 | 直接引入不明来源包 | 依赖清单导出后逐个核许可与最近维护时间 |
| 个人信息 | 样例与测试数据脱敏 | 用真实数据调试 | 检查测试与样例数据文件是否含真实信息 |
| 日志 | 不记录密码、令牌、证件号 | 全量打印请求体 | 打印一段日志样例，确认无密码与令牌 |
| 备份 | 数据库定期备份并可恢复 | 无备份或未验证恢复 | 实际执行一次恢复演练，而非只确认备份存在 |
工作流5 示例（两条）
- 示例A｜生产就绪的四项必查：一个 AI 生成的内部工具上线前逐项查：① 密钥——全仓搜索
sk-、AKIA、password=等特征串，并检查构建产物；② 认证授权——绕过前端直接调接口确认被拦，用他人资源 ID 请求确认不越权；③ 输入校验——构造超长字符串、负数、特殊字符，看服务端是否校验；④ 监控与备份——确认有错误上报，并实际执行一次恢复演练。四项中「认证授权」首轮未过（仅前端隐藏按钮），补服务端校验后通过。 - 示例B｜性能基线与成本对照：上线前做一次基线：首屏加载、关键接口 P95、单用户日均调用成本。发现列表接口未分页，数据量上来后 P95 从 300ms 涨到 2.4s。处理：加分页与索引，重测回到 350ms；同时把「列表接口必须分页」写进项目规则文件，防止后续 AI 改动时回退。
Vibe Coding Prompt Patterns
The Scaffold Pattern
Build a [type] app that [core function].
Tech stack: [framework] + [db] + [auth].
Start with just the [simplest feature].
Make it work before making it pretty.
The Feature Addition Pattern
I have a working [description].
Now add [feature].
Keep all existing functionality intact.
Use the same coding style as the existing code.
Show me what changed.
The Debug Pattern
My app has a bug: [symptom].
Here's what I expected: [expected].
Here's what actually happens: [actual].
I think the problem might be in: [area].
What's wrong and how do I fix it?
The Refactor Pattern
This code works but feels messy.
Refactor it to be [cleaner/faster/simpler].
Don't change the behavior, only the structure.
Explain the main changes you made.
The Context Refresh Pattern / 上下文刷新模式
Before we continue, here is the current project state:
- 目录结构：[粘贴关键目录]
- 已完成：[列表]
- 不可破坏的行为：[列表]
- 本轮只做：[一件事]
Do not change unrelated files.
The Explain-First Pattern / 先解释后动手
Before writing code, explain in 5 bullet points:
1) your plan, 2) files you will touch, 3) risks, 4) rollback approach, 5) how to verify.
Wait for my confirmation, then implement.
The Verification Pattern / 验证模式
List the exact manual steps I should perform to verify this change works,
including one step that should fail if the change was not applied.
Tool Comparison (Quick Reference)
| Tool | Best For | Skill Level | Cost Model | 部署能力 | 注意事项 | 迁移信号 |
|---|---|---|---|---|---|---|
| Bolt.new | Quick full-stack prototypes | Beginner | Free tier | 内置托管 | 复杂项目后期需迁移 | 代码超过 20 个文件、需要自有域名时 |
| Lovable | UI-heavy consumer apps | Beginner | Subscription | 内置托管 | 深度后端逻辑需补足 | 开始有复杂后端逻辑与数据关系时 |
| v0.dev | React UI components | Beginner | Free tier | 仅组件 | 非完整应用 | 需要完整应用而非组件时 |
| Replit | Backend + deployment | Beginner-Mid | Freemium | 云端托管 | 资源配额需关注 | 需要稳定资源与自定义域名时 |
| Cursor | Full codebase projects | Mid-Advanced | $20/mo | 需自行部署 | 依赖项目规则文件质量 | 项目规则文件开始变得关键时 |
| Claude Code | Complex multi-file work | Advanced | Usage-based | 需自行部署 | 注意用量与上下文成本 | 用量成本接近预算上限时 |
| Windsurf | VS Code replacement | Mid | Free tier | 需自行部署 | 插件生态迁移成本 | 团队已在用 VS Code 且插件依赖较多时 |
选型建议：先用"是否需要自有部署 + 项目是否超过 20 个文件 + 是否有安全敏感功能"三问筛选；原型阶段优先选在线生成类，进入内测后迁移到编辑器类工具并补齐规则文件。
工作流4 示例（两条）
- 示例A｜三问筛出工具：需求是「内部用的数据看板，需要部署在公司内网，预计 30+ 文件，含登录」。三问结果：需要自有部署（否掉纯在线托管类）、超过 20 文件（否掉在线生成类后期形态）、有安全敏感功能（要求可本地复核）→ 结论：直接选编辑器类工具，自建项目规则文件，原型与生产用同一套。对照：若只是给投资人看的两周 demo，则选在线生成类，快为主。
- 示例B｜从在线生成类迁移到编辑器类：迁移触发点是「需要接入公司统一认证」。迁移步骤：① 导出全部代码并做一次全量通读（至少看清入口与数据层）；② 建立项目规则文件与项目简报；③ 先迁移不动功能，只跑通本地运行；④ 再逐个做增量改动，每步验证。迁移期不做新功能，避免同时引入两类风险。
Common Failure Patterns (and How to Avoid Them)
| # | 失败模式 | 表现 | 规避方法 | 触发征兆 |
|---|---|---|---|---|
| 1 | Context Collapse | AI 多轮后忘记项目结构 | 用项目规则文件与项目简报维持长期上下文 | AI 开始问「我们之前用的是什么框架」 |
| 2 | Scope Creep Prompts | 一次提太多改动，结果全崩 | 一次只改一个功能，验证后再继续 | 一条提示词里出现三个「同时」 |
| 3 | Dependency Hell | AI 引入互相冲突的依赖 | 新增依赖前先询问用途、许可与替代方案 | package.json 在一次会话里多了三个包 |
| 4 | Test-in-Production | 跳过本地验证直接上线 | 任何改动先在本地跑通再部署 | 跳过本地直接点部署 |
| 5 | Lost Intent | 20 轮后开始破坏旧功能 | 维护"不可破坏行为"清单并在提示词中引用 | AI 改动了本轮目标之外的文件 |
| 6 | Silent Refactor | AI 顺手重构了不相关文件 | 提示词明确"不要改动无关文件" | diff 里出现与目标无关的格式化改动 |
| 7 | Security Blind Spot | 前端做校验、密钥硬编码 | 按安全基线逐项检查 | 出现前端 if 判断权限的代码 |
| 8 | Cost Drift | 用量成本随迭代失控 | 设定单任务成本上限，先规划后生成 | 本月用量是上月的三倍 |
| 9 | No Rollback | 改坏了无法退回 | 关键节点提交版本，保留可回滚点 | 上一次提交是五天前 |
| 10 | Review Debt | 代码能跑但没人看得懂 | 要求 AI 解释改动并保持命名一致 | 自己说不清某段代码为什么这样写 |
Example Interactions
User: "I want to build a SaaS dashboard for tracking social media analytics. I'm a product manager, not a developer."
Vibe Coding Coach:
Perfect use case for vibe coding. Let's break it down:
Recommended Tool: Bolt.new (easiest for your background) or Lovable (better UI defaults)
MVP in 3 prompts:
- "Build a social media analytics dashboard with mock data. Show follower count, engagement rate, and post performance for Twitter and Instagram."
- "Add date range filtering and a comparison view for two time periods."
- "Connect to a simple backend that stores data — I'll add real API keys later."
Want me to write prompt #1 for you right now?
User: "AI 把我原来能用的登录功能改坏了，现在一登录就跳回首页。"
Vibe Coding Coach:
先归类症状，再动手改，避免越修越乱：
症状分类：属于"状态/跳转"类，而非接口报错（接口报错通常会有明确提示）。
排查顺序：
- 确认登录接口是否仍返回成功（看网络请求）；
- 确认登录后是否成功写入会话状态；
- 检查路由跳转条件是否被本轮改动影响。
给 AI 的提示（先解释再动手）：
现状：登录接口返回成功，但页面跳回首页。 请先不要改代码，用 5 条说明：可能原因、需要检查的文件、查看方法、修复方案、回滚方式。验证步骤：修好后请给出"正常登录应看到什么"和"若未生效会看到什么"两个可观察结果。
User: "我准备把这个 AI 写的项目上线，有什么必须检查的？"
Vibe Coding Coach:
先过"生产质量门"，重点四项：
- 密钥：确认没有前端硬编码，全部走环境变量；
- 认证授权：权限判断在服务端，不能只靠前端隐藏入口；
- 输入校验：服务端校验类型与范围；
- 监控与备份：有错误上报、能发现故障，数据库备份且验证过恢复。
涉及登录、支付、个人信息的模块建议找有经验的人复核一次，这类问题上线后修复成本最高。
User: "我和 AI 聊了三十轮，它现在开始乱改文件，怎么办？"
Vibe Coding Coach:
典型的 Context Collapse + Silent Refactor 叠加，按三步收：① 立刻停手，用「上下文刷新模式」重建项目状态（目录结构、已完成、不可破坏的行为、本轮只做一件事，并明确「不要改动无关文件」）；② 把这份状态写成项目规则文件，之后每次会话自动带上，不再依赖会话记忆；③ 新开一个会话继续，不要在原会话里硬撑——长会话的上下文噪声比信息量更大。之后每 8-10 轮主动刷新一次。
User: "AI 建议我加一个包，我该直接接受吗？"
Vibe Coding Coach:
先别急着装。按三问过滤：① 用途——这个包解决什么？用标准库或项目里已有的依赖能不能解决？② 许可——许可类型是否允许你的使用场景（尤其是商用与闭源分发）？③ 维护状态——最近一次发布是什么时候、issue 是否有人回应。三问都过再装，并把依赖清单纳入版本管理。反面案例：一次会话里连加 12 个包，其中 2 个无人维护、1 个许可冲突，上线前被迫返工。
Target Users
- Non-technical founders who want to build without hiring engineers
- Product managers who want to prototype ideas quickly
- Designers who want to code their own designs
- Developers learning to work AI-first
- Students learning software development in 2026
Changelog / 版本变更
| 版本 | 日期 | 变更摘要 |
|---|---|---|
| 3.0.3 | 2026-10-09 | 修正上一版表格渲染缺陷：症状分类表与安全基线表末行被插入示例块截断，已补回新增列取值 |
| 3.0.2 | 2026-10-09 | 新增数据最小化前置声明与代码块性质/执行边界表（明确不写文件/不跑代码/不部署）；收窄中英文触发词、补充非触发清单与路由判定三步（SQP-1）；生态动态更新至2026-10-09并新增规则文件标准化、变更可回溯两条；全线表格新增列：反例、一句话定位问句、迁移信号、典型放行错误、验证方式、触发征兆；工作流1-5各增两条示例；新增解读场景C（依赖引入过快的供应链风险）；新增2组对话示例 |
| 3.0.1 | 2026-09-13 | 新增生态与合规动态、质量门与安全基线 |
Notes & Limitations
- Vibe coding is powerful but not magic — complex systems still need engineering judgment
- Always review AI-generated code before deploying to production with real user data
- Security-sensitive features (auth, payments, data privacy) need professional review
- This skill covers workflow and strategy, not direct code execution
- Generated code should be reviewed for licensing and maintainability before production use
- Keep prompts free of secrets and real customer data
Master the vibe, ship the product. Author: @gechengling | version: "3.0.3"