前言
你在使用 AI 编程的过程中，是否有这些感受？
作为问题解答工具，AI 上手非常快，并且比搜索引擎更能懂得你的需求，但是，在现实辅助编码过程中，往往发现，生成结果和预期还差了一点，比如：
- 生成代码不符合团队规范；同一类组件，没有使用项目中已存在的，而是自己又搞了一套；再或者针对有点规模的系统，会出现考虑不全的情况。
其实，抛开 AI 不谈，即使是人与人协作，也常常会遇到类似的问题，不是吗？
- 总有人不愿意遵循团队规范，需要进行代码检查、代码审查；也总有人不愿意看项目文档，直接根据需要引入新的依赖；再或者，有人修复缺陷的时候，仅关注缺陷自身，一点不关注缺陷修改是否影响到其它关联模块。
AI 编程的问题，好像也不仅仅是 AI 编程的问题~
上面这个课题比较深，后续我们慢慢探讨。
今天，我们不妨借鉴现实团队通过完善文档来解决协作问题的思路，看看这种方法能否同样提升 AI 编程的效果。
下面，开始案例实操对比。
实战背景及任务
背景
依然是我们内部的协同办公平台，整个项目后端采用 Spring Boot + 原生Mybatis 实现，数据库采用的 MySQL，前端采用 Vue2 + Element UI。
平台中有一个“项目管理”模块，其中每个项目会有很多文档，我们日常使用企微作为文档协作和存储工具。
但是企微的微盘入口，加上我们自己的文件夹结构，导致每个文档都藏的比较深，使用起来没有那么方便。
任务
今天，我们就为“项目管理”模块增加一个“项目文档”功能，将常用的文档链接关联到项目中，大幅减少访问文件的操作步骤。
任务包含“项目文档”的前后端代码，我们将通过 Cursor 一键生成。
操作过程
实操环境：Cursor 1.0 + Claude-4-Sonnet。
分析设计
需求描述：
实现项目文档的基础管理（增删改查），包括：关联的项目、文档名称、文档描述、文档URL、备注。
建表SQL
Ask模式。
提示词：
请帮我设计“项目文档”模块基于mysql的sql，表名为：project_document，该模块主要用于存储企微在线文档地址，方便用户访问：项目文档字段包括：关联的项目、文档名称、文档描述、文档URL、备注。参考以下sql：---CREATE TABLE `project_base` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `create_by_id` bigint(20) DEFAULT NULL COMMENT '创建人ID', `dept_id` bigint(20) DEFAULT NULL COMMENT '创建人机构ID', `create_by` varchar(64) COLLATE utf8_bin DEFAULT '' COMMENT '创建者', `create_time` datetime DEFAULT NULL COMMENT '创建时间', `update_by` varchar(64) COLLATE utf8_bin DEFAULT '' COMMENT '更新者', `update_time` datetime DEFAULT NULL COMMENT '更新时间', `remark` varchar(1000) COLLATE utf8_bin DEFAULT NULL COMMENT '备注', `contract_id` bigint(20) DEFAULT NULL COMMENT '合同ID', `project_name` varchar(100) COLLATE utf8_bin DEFAULT NULL COMMENT '项目名称', `project_code` varchar(100) COLLATE utf8_bin DEFAULT NULL COMMENT '项目编号', `project_type` varchar(100) COLLATE utf8_bin DEFAULT NULL COMMENT '项目类型', `project_description` text COLLATE utf8_bin COMMENT '项目详细描述', `start_date` date DEFAULT NULL COMMENT '项目开始日期', `end_date` date DEFAULT NULL COMMENT '项目预计结束日期', `actual_end_date` date DEFAULT NULL COMMENT '项目实际结束日期', `project_status` varchar(100) COLLATE utf8_bin DEFAULT NULL COMMENT '项目状态', `manager_user_id` bigint(20) DEFAULT NULL COMMENT '项目经理', `relate_document` varchar(255) COLLATE utf8_bin DEFAULT NULL COMMENT '关联文档', `geo_location` varchar(255) COLLATE utf8_bin DEFAULT NULL COMMENT '地理坐标信息', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=24 DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='项目信息表';---结果：
代码生成（无文档）
上下文
项目文档表建表sql。
提示词
实现项目文档表的前后端代码。结果
后端部分
前端部分
效果
列表页面
录入页面
小结
整体生成结果很不错，差点让我以为找不到优化的地方了...
目前发现存在的问题：
- 第一、页面没有完全按照其它页面规范生成。
- 列表页面没有一点问题，自动根据我们的样式改造了。录入页面不符合我们规范，我们不建议使用弹窗，无法切换 tab 使用。
补充一句，Cursor 0.5.0 之后，支持多工程项目，就像本文，Cursor 可以直接找到前后端两个工程，并一口气生成。
代码生成（带文档）
上下文
项目文档表建表sql。
项目规约.md
项目规约部分截图：
提示词
和提升前完全一致。
实现项目文档表的前后端代码。结果
效果
小结
可以看到，在“项目规约.md”的约束下，结果已经按照预期的进行了优化。
- 第一、录入界面参考项目统一样式实现。第二、自动按照约定生成菜单 sql。第三、自动根据建表 sql，创建所需字典 sql。
对比结果
为了展示思路的通用性，模块挑选的很普通，对比效果并不是很强烈，如果是业务关联更深入的模块，应该对比会更强烈些。
思路其实很简单，甚至可能很多人都在有意无意的使用。
通过一个 md 文件，将真人团队协同所需的内容以文档的方式提供给 AI 对话，这个 md 文件可以是项目规约，可以是需求文档。
最主要的是，它应该是一个持续完善的文档。
随着这个文档的完善，你对 AI 编程的结合才会更加深入，更加高效。
我们告诉真人什么，就告诉 AI 什么。
也许有人会说大模型有幻觉，不靠谱。
但我认为当下 AI 的幻觉相对来说已经非常轻了，尤其是结合一些上下文和方向性提示词，足够支撑我们日常开发使用了。
在我看来，如果一个团队的人员都达到了 Cursor + Claude 4 的思维程度（不做知识面对比），我感觉这个团队已经挺厉害了。
结语
这次分享，其实和上周 Cursor 1.0 发布有点关系。
Cursor 1.0 发布了 Memories 特性，这个功能，十分类似我们今天分享的内容，只是 Cursor 将这个文件内置了，并可以通过对话进行更新。
那 Cursor 1.0 后今天这个技巧是否就没用了？
个人感觉应该不会。一方面，这个 Memories 好用起来估计还需要我们贡献更多的用例反馈，另一方面，Cursor 中 AI 从对话中 get 到的点不一定完全符合你的预期，还是存在很多场景需要大家手动进行指导的。
好了，希望大家可以实践下这个思路，如果有什么问题或者可以优化的点，欢迎交流~
最近 《AI 编程实战》 系列估计会有3-5篇内容集中分享一些相关的实用技巧，你如果对这方便比较关注，可以点个星标，方便下次找到我哈。
