面向项目开发使用 AI 编程的痛点
面向项目开发是目前大部分公司，特别是外包型公司的一大特点，这类公司开发的产品有几个特点：需求直接面向客户、功能定制化程度高、版本迭代节奏快。为了统一公司产品的风格和交互，往往也会有自己的定制化产品组件库，这种组件库的风格和使用方式与社区通用组件存在一定的差异化，甚至有一些是针对业务进行定制化改造的调整。对于这类产品想要找到一个开箱即用的 AI 开发方案基本是不可行的，或者说能发挥的效果有限，主要体现在：
- 通用的最佳实践方案在项目中不适用，需要对方案进行大量修改、适配后才能真正落地运行
- AI 对公司私有组件库、内部封装工具、业务脚手架不熟悉，生成代码频繁出现组件名错误、API 用法不对、样式不兼容等问题
- 项目业务规则复杂且高度定制，AI 难以理解客户专属的业务逻辑、审批流、权限体系，生成代码逻辑漏洞多，后期排查成本高
- 版本迭代快、需求频繁变更，AI 难以跟上项目历史代码上下文，新增功能时容易与原有逻辑冲突，兼容性问题突出
- 外包项目普遍存在老旧代码、历史遗留逻辑、非标准写法，AI 重构或二次开发时容易破坏原有功能，风险不可控
- 客户需求模糊、频繁调整，AI 缺乏对客户沟通、需求澄清、范围界定的能力，仍需人工梳理后才能使用，效率提升有限
- 公司内部有严格的编码规范、目录结构、命名约定、发布流程，AI 生成代码风格杂乱，格式化、整改工作量大
- 涉及客户敏感数据、内部接口、私有部署环境，AI 无法访问真实业务场景，只能生成“空壳代码”
破局——做好规则和技能
以上痛点是我在做一个项目的 AI 编程试点时真实遇到的问题，我的破局思路是做好规则和技能
规则：项目的约束与护栏
通过规则来约束代码的风格、格式化和一些组件的写法规范，比如 必须使用公司的私有组件库，禁止直接使用 elment-ui、编码完成必须遵循项目的 ESLint 规范，确保代码风格统一和质量，规则越清晰具体，AI 输出越贴合项目实际，能大幅减少后期整改成本。
规则并非一成不变，在实际的项目实践过程中可以逐渐完善，比如发现 AI 代码存在规则相关问题（如违规使用组件、不符合项目开发规范），可按照 存在xxx问题（明确AI代码违规点）→ 应该怎么做（制定具体整改方案）→ 完成代码和相关文档修改，并完善xxx规则（补充或优化对应规则） 的提示词逻辑，持续优化规则细节，让规则更贴合项目实际需求，逐步规范 AI 输出。
技能：过程的指导说明书
根据通用的业务场景（比如文件上传、表单输入、明细数据展示、图表展示、弹窗配置等）制定对应的技能，来指导AI在特定业务场景下如何编写代码，如何调用服务，如何使用组件。结合 CodeBuddy 官方 Skill 最佳实践，我总结的写技能的技巧如下：
- 场景化命名，直接对应业务场景（如form-create、upload-file），便于AI识别；
- 精准描述触发条件，明确技能适用场景，确保AI按需调用；
- 用动词开头的指令式语言，避免描述性语句，直接明确操作要求；
- 遵循渐进式披露原则，元数据轻量加载，核心指令触发时加载，扩展资源按需加载；
- 分离核心指令与扩展资源，SKILL.md 存核心规则，参考文档、模板、脚本分别归类存放；
- 坚持单一职责，一个技能解决一类场景，便于维护复用，且与公司规则强绑定。
技能本质是模块化、可复用的能力包，能让通用AI快速成为贴合项目的专属助手，同时沉淀团队最佳实践，降低适配成本。与规则类似，场景技能也需结合项目实践持续迭代完善，当发现 AI 代码存在场景适配问题（如组件调用错误、业务逻辑缺失），可采用 存在xxx问题（明确AI代码在特定场景下的漏洞）→ 应该怎么做（给出具体解决方案和正确代码示例）→ 完成代码和相关文档修改，并完善xxx技能（补充该场景下的技能细节、指令规范）的提示词逻辑，逐步丰富技能场景、优化指令细节，让 AI 不断学习项目实践经验，越来越“聪明”，输出的代码也越来越贴合项目实际需求。
基于项目开发最佳实践流程——SPEC CODING
SPEC-CODING 是AI时代的开发基石，即以规格说明（specification ）为核心驱动，实现从规范定义到代码实现的精准映射与自动化交付的工程范式，简单说就是先制定“规范的文档”，然后再让AI根据这个文档去拆解任务、执行编码、迭代交付，具体在项目中的操作流程如下：
编写文档 → AI 搭建初始框架 →多轮对话完善开发 → 审查代码/验证功能 → 发现问题/优化需求 →持续迭代
需要重点补充的是，流程中的编写文档环节可与前文提到的技能体系深度结合，接口文档、需求设计文档等核心文档，均可以编写成对应的技能。通过提前编写规范的文档模板，将文档的格式、内容要点、编写标准沉淀为专属技能，让 AI 能够根据需求描述、原型图等信息，自动输出规范、完整的设计文档，既减少人工编写文档的工作量，也能保证文档的统一性和规范性，为后续 AI 搭建框架、开发功能奠定坚实基础，进一步提升整体开发效率。
常见的问题处理方案
| 问题类型 | 问题描述 | 处理方式 |
|---|---|---|
| 功能偏差 | 与原型/需求偏差较大，界面完全不可用 | 撤销代码修改 → 检查并调整文档说明 → 重新执行 |
| 功能缺失 | 大部分功能可用，但小部分功能缺失 | 直接告知大模型："xxx 功能没实现，请仔细查看设计文档完成开发" |
| 运行报错 | 代码运行错误或浏览器页面报错 | 直接将报错信息贴到对话框，大模型会自行检查并修正 |
| 细节问题 | 缺少字符校验、数据格式问题、样式问题、没有提示等 | 直接对话告知具体要求，如"创建时间用年月日的格式" |
| 经验问题 | 人工可凭借经验快速解决的问题 | 人工直接修改代码，效率最高 |
| 代码审查 | 功能验证和代码质量检查 | 把 AI 当做优秀实习生，指出问题让其修改 |
总结
前期刚开始引入 AI 编程到项目中，确实是一步一个坎，规则和技能也调了很多轮才能达到一个基本稳定的输出，但是当规则和技能足够完善后，只要需求描述没有太大的偏差，基本上 AI 生成的代码都是一次过，代码可用率可以达到 80% 以上，剩余的 20% 也基本可以通过提示词直接让 AI 帮你解决，这个对开发效率的提升还是挺大的。
AI 编程是一个持续迭代的过程
不要期望一次对话就能完成所有功能。在实际开发中，建议遵循以下迭代策略：
- 小步快跑：将大需求拆分成多个小任务，逐个完成并验证
- 快速验证：每完成一个功能模块，立即进行测试和验证
- 及时反馈：发现问题立即反馈给 AI，避免问题累积
AI 编程质量的取决因素
AI 编码的质量我觉得取决于几个要素：
- 规则的约束性
- 技能的完整性
- 需求描述的准确性
- 模型的能力（目前看头部模型好像都大差不差，glm5/kimi-k2.6/minimax 2.6 感觉都可以），其中 kimi 生成的文档质量我觉得是最好的，而且支持多模态，能直接把原型图和设计图丢给他去做分析，挺方便的
- 开发者的架构思维（一些复杂的模块需要开发者提供组件/模块的设计思路）
开发者的角色定位
开发者在这个里面的角色定位我觉得更像一个“决策者”，决策代码是否可用，决策架构设计，决策设计方案
