关于大型项目，使用 AI 的实践问题

[hytex]

关于使用 Codex 进行大型项目开发时遇到的问题

RT ，一直在使用 AI 进行编码工作，目前使用的是 Codex Pro 版本。随着项目规模逐渐扩大，一些问题也开始逐渐显现。

1. 全局提示词作用有限

针对这个问题，我已经尝试过多种方式优化全局提示词，包括但不限于精简提示词、对提示词进行功能分区等，但实际效果仍然不够理想。

具体问题： 已经在提示词中明确要求，编码完成后必须使用相关工具对代码进行格式化，但实际执行过程中仍然无法保证这一要求得到贯彻。

2. 代码质量逐渐下降

这个问题实际上也可以归属于第一个问题，但随着项目代码量的增加，其表现变得更加明显。

具体问题： 已经在提示词中提供了 MyBatis-Plus 的使用示例，并明确规定了相关编码规范，但 AI 仍然会出现不符合项目规范的写法。

例如，在 Mapper 接口中直接使用注解编写简单 SQL ，而不是按照项目既定的方式编写 SQL 。假设需要查询学生表中的 id 和 name 字段，AI 可能会直接在接口中写入：

@Select("select id, name from student where id = #{id}")

3. 代码风格缺乏统一性

这也是第二个问题的延伸。随着项目规模不断扩大，后续生成的代码越来越难以保持统一的编码风格和实现规范，导致不同模块、不同功能之间的代码一致性逐渐下降。

想请教的问题

针对以上三个问题，有哪些比较成熟、有效的最佳实践？

[Absofknglutely]

不说了, 直接建议 claude

[charsunny]

提示词里写的它确实会忘，我后来能用脚本卡住的就用脚本卡，写在 AGENTS.md 里的只当提醒。风格不统一我也一直有，让它照着现成的模块写会好点。

[leadfast]

大型是多大, `cloc src` 多少

[Hypn0s]

1. 格式+调用规范+代码复杂度等可以通过 AST 检测做到的, 用 commit 的 hook 脚本拦住;
2. 代码建议+最佳实践类, 按照 checklist 或者评分制, 用 mr 的流水线 agent 拦住.

[hytex]

@Hypn0s 所以相当于是还是得通过一些 hook 的方式去整体的进行调整？

[hytex]

@leadfast 没有去统计过，但确实是一个完整的 saas 系统。

[Hypn0s]

@hytex 对, 硬规则用硬约束, 软规范用 agent

[getadoggie]

全局提示词得使用机制，钩子脚本等。不能靠不确定的提示词。然后就是每个 agent 的信息密度要小些，大的话处理不过来的，会丢三落四。

[wqhui]

强制性的东西要靠脚本，提示词只能是让 ai 有这倾向

[94]

@hytex #5 ，固定的流程肯定是固化成脚本来做啊。稳定、速度快还没开销。

[hytex]

@94 固定的我理解，但是对于第二点，这种在 coding 的过程中出现的编码问题，我还没找到有什么好的方式去处理这个问题。

[RandomJoke]

要精确统一，你就得加审查，把 AI 当高效干活的人来管理，错的时候告诉他错了。

[zhady009]

用 Sol 的模型没遇过，会跟着仓库代码风格来实现不用自己说只有用 Luna 会出现不跟风格的情况，从 0 开始的项目我自己有总结想要的代码风格给 LLM 参考

[hytex]

@zhady009 我这也算是从 0 开始的，所以规范性质的东西是一开始就已经写好了的，但是越到后边，这种不按规范进行编写的就越多了

[hytex]

@RandomJoke 这就是我现在 review 出来的问题，你的意思是再加一个 agent ，专门用来做审查？

[RandomJoke]

@hytex 加 agent 也能解决大部分问题，就是 5% 出错 得叠加另一个审查也 5% 出错，本身审查 agent 可能更简单一点，出错概率更小。追求完全正确，就用类似 sonar 的程序化审查