AI编程的“能力边界”在哪里？

一、引言：一个 Markdown 文件为何火遍 GitHub

最近，一个名为andrej-karpathy-skills的开源项目在 GitHub 上热度飙升。它不是一段精巧的算法实现，也不是一个全新的框架，而是一份不足 70 行的 Markdown 文件——CLAUDE.md。这个项目已在 GitHub 上累计获得超过 91k star，一度霸榜 GitHub Trending 日榜第一。

一个非功能文件能获得如此高的关注度，背后的原因并不复杂：它击中了当前 AI 编程最真实的矛盾——瓶颈已不在模型本身，而在于模型周围的“脚手架”和“纪律”。

二、AI 编程为什么必须用约束规范？

1. LLM 天生有「行为缺陷」

大模型的核心训练目标是预测下一个 Token，并非贴合工程思维、严谨落地开发。
天然存在思维短板：

• 优先无脑补全，不会主动质疑需求、发现边界问题
• 输出表述模糊化，缺少精准逻辑与落地细节
• 过度泛化发散，容易偏离项目原有架构与风格

没有约束 = AI 自由发挥 = 代码质量失控 = 埋下线上隐患与维护债务。

2. 约束规范：将资深工程师隐性经验，转化为 AI 可识别规则

andrej-karpathy-skills 核心四大工程铁律，也是AI编程的核心约束：

1. Think Before Coding：拒绝主观臆断，需求模糊主动澄清，不擅自脑补业务逻辑
2. Simplicity First：极简优先，拒绝过度设计、冗余抽象、无效复杂化
3. Surgical Changes：外科式精准修改，只改动目标代码，不侵入无关文件、不乱删原有逻辑与注释
4. Goal-Driven Execution：以最终目标为导向，完成后提供校验依据，保证代码可运行、可验证

3. 约束不是限制能力，而是放大AI编程价值

• 无规范约束：AI 堆砌冗余代码、逻辑混乱、改崩项目，开发者花费大量时间返工修Bug
• 有规范约束：AI 产出简洁、合规、贴合项目风格的高质量代码，减少调试、重构成本

核心结论：AI 编程时代，模型能力决定下限，约束规范决定代码质量上限。

三、Cursor 中配置 andrej-karpathy-skills

在项目中新建.cursor/rules/karpathy-guidelines.mdc文件

项目根目录

├── .cursor/ │ └── rules/ │ ├── karpathy-guidelines.mdc │ ├── xx1.mdc │ └── xx2.mdc

• karpathy-guidelines.mdc 文件如下

--- description: Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria. alwaysApply: true --- # Karpathy Behavioral Guidelines (Karpathy 行为准则) Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed. (旨在减少常见 LLM 编码错误的行为准则。请根据项目具体情况合并使用。) **Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment. (权衡：这些准则偏向于谨慎而非速度。对于琐碎的任务，请自行判断。) ## 1. Think Before Coding (编码前先思考) **Don't assume. Don't hide confusion. Surface tradeoffs.** (不主观假设、不掩盖疑问、明确方案取舍与权衡。) Before implementing: - **State your assumptions explicitly.** If uncertain, ask. (明确陈述你的假设。如果存在不确定点时主动提问确认。) - **Present multiple interpretations.** If they exist, don't pick silently. (如果存在多种理解，请列出来——不要默默选择。) - **Push back when warranted.** If a simpler approach exists, say so. (若存在更简洁的实现方式，主动说明。) - **Name what's confusing.** If something is unclear, stop and ask. (如果有什么不清楚，停下来，指出困惑点并提问。) ## 2. Simplicity First (简约至上) **Minimum code that solves the problem. Nothing speculative.** (用最少代码解决核心问题，杜绝多余、试探性冗余实现。。) - **No features beyond what was asked.** (不要添加未被要求的功能。) - **No abstractions for single-use code.** (不要为只使用一次的代码创建抽象。) - **No "flexibility" or "configurability"** that wasn't requested. (不要添加未被要求的“灵活性”或“可配置性”。) - **No error handling for impossible scenarios.** (不要为不可能发生的场景做错误处理。) - **Rewrite if over-engineered.** If you write 200 lines and it could be 50, rewrite it. (如果你写了 200 行但本可以 50 行解决，请重写。) Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify. (问自己："资深工程师视角判断是否存在复杂化"，若有，立即简化。) ## 3. Surgical Changes (精准最小改动) **Touch only what you must. Clean up only your own mess.** (仅修改必要代码，只清理本次改动衍生的冗余问题。) When editing existing code: - **Don't "improve" adjacent code**, comments, or formatting. (禁止擅自优化无关代码、注释、代码格式。) - **Don't refactor things that aren't broken.** (不要重构没坏的东西。) - **Match existing style**, even if you'd do it differently. (严格遵循项目现有代码风格，保持上下文统一。) - **Mention unrelated dead code**, don't delete it. (发现无关历史死代码仅做备注提醒，禁止擅自删除。) When your changes create orphans: - **Remove imports/variables/functions** that YOUR changes made unused. (移除因你的修改而变得无用的导入/变量/函数。) - **Don't remove pre-existing dead code** unless asked. (除非被要求，否则不要移除原本就存在的死代码。) The test: Every changed line should trace directly to the user's request. (检验标准：每一行修改都应该直接追溯到用户的请求。) ## 4. Goal-Driven Execution (目标驱动执行) **Define success criteria. Loop until verified.** (定义成功标准。循环直到验证通过。) Transform tasks into verifiable goals: - "Add validation" → "Write tests for invalid inputs, then make them pass" - "Fix the bug" → "Write a test that reproduces it, then make it pass" - "Refactor X" → "Ensure tests pass before and after" For multi-step tasks, state a brief plan: 1. [Step] → verify: [check] 2. [Step] → verify: [check] 3. [Step] → verify: [check] Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification. (强有力的成功标准让你能独立闭环。弱标准（如“让它跑通”）则需要不断的澄清。) --- **These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes. (如果这些准则生效了，你会看到：Diff 中不必要的变更减少，因过度复杂导致的重写减少，以及澄清性问题出现在实现之前而不是错误之后。)

四、AI 编程的能力边界

有了约束规范加持，AI 编码效率与稳定性大幅提升，但AI并非万能，依旧存在清晰的能力边界与局限性。

✅ AI 擅长（规则可控范围内）

• 快速落地明确需求：常规业务开发、通用组件封装、工具函数编写、CRUD 逻辑实现
• 代码工程化处理：代码格式化、风格统一、冗余重构、补全注释、简化冗余逻辑
• 基础问题排查：语法错误修复、简单逻辑 Bug 调试、环境配置问题优化
• 标准化产出：编写单元测试、生成文档、适配项目现有编码规范
• 遵循约束执行：在 Karpathy 规范限制下，做到最小改动、极简实现、不随意扩写逻辑

❌ AI 不擅长（核心能力短板）

• 业务与产品决策：只能执行需求，无法自主判断业务合理性、功能取舍、产品边界
• 复杂架构设计：分布式架构、数据库分层、性能优化、高可用方案等深度架构设计
• 复杂深度业务：强行业规则、长链路业务逻辑、历史复杂遗留系统改造
• 全局风险判断：无法完整感知项目技术债务、隐性耦合、线上潜在风险
• 百分百合规约束：即便配置规则，复杂场景仍会偶尔越界，需要人工复核校验

关键结论

AI 是高效执行的编码执行者、高级辅助实习生，但无法替代工程师的架构思维、业务判断力与风险把控能力。
合理认知AI能力界线，人机分工、人工终审，才是AI编程的正确使用方式。

五、总结与思考

回到 andrej-karpathy-skills 这个项目，它之所以能引发如此广泛的共鸣，本质上在于它回应了一个时代命题：当模型能力已经足够强大时，真正稀缺的已经不是“如何让 AI 写出代码”，而是“如何让它写出对的代码、不改不该改的东西、在不确定时停下来问”。是一次开发思维的升级。它让我们从与 AI 的“博弈”中解脱出来，进入一种更加可控、更加高效的协作流。