- hytex2026-10-14
关于使用 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. 代码风格缺乏统一性这也是第二个问题的延伸。随着项目规模不断扩大，后续生成的代码越来越难以保持统一的编码风格和实现规范，导致不同模块、不同功能之间的代码一致性逐渐下降。
想请教的问题
针对以上三个问题，有哪些比较成熟、有效的最佳实践？
主楼 - Absofknglutely2026-10-14
不说了, 直接建议 claude
- charsunny2026-10-14
提示词里写的它确实会忘，我后来能用脚本卡住的就用脚本卡，写在 AGENTS.md 里的只当提醒。风格不统一我也一直有，让它照着现成的模块写会好点。
- leadfast2026-10-14
大型是多大,
cloc src多少 - Hypn0s2026-10-14
1. 格式+调用规范+代码复杂度等可以通过 AST 检测做到的, 用 commit 的 hook 脚本拦住;
2. 代码建议+最佳实践类, 按照 checklist 或者评分制, 用 mr 的流水线 agent 拦住. - hytex2026-10-14
- 942026-10-14
，固定的流程肯定是固化成脚本来做啊。稳定、速度快还没开销。
- hytex2026-10-14
- Hypn0s2026-10-14
- getadoggie2026-10-14
全局提示词得使用机制，钩子脚本等。不能靠不确定的提示词。然后就是每个 agent 的信息密度要小些，大的话处理不过来的，会丢三落四。
- wqhui2026-10-14
强制性的东西要靠脚本，提示词只能是让 ai 有这倾向
- hytex2026-10-14
- RandomJoke2026-10-14
要精确统一，你就得加审查，把 AI 当高效干活的人来管理，错的时候告诉他错了。
- zhady0092026-10-14
用 Sol 的模型没遇过，会跟着仓库代码风格来实现不用自己说只有用 Luna 会出现不跟风格的情况，从 0 开始的项目我自己有总结想要的代码风格给 LLM 参考
- hytex2026-10-14
- hytex2026-10-14
@RandomJoke 这就是我现在 review 出来的问题，你的意思是再加一个 agent ，专门用来做审查？
- RandomJoke2026-10-14
- zhangli29462026-10-15
在于分离问题的通用部分和专用部分。
通用部分，AI 在给出少量知识可以做的足够好。
专用部分，上下文给到足够也可以做到足够好。eg:
低频业务 API 分发到供应商 API Server 的调用中转服务。分发执行(业务无关)用 .http 文件(Jetbrains HTTPClient 语法)解释执行器
分发规格(业务有关)用 minijinja 结合参数渲染为 (Jetbrains HTTPClient 语法） 脚本片段扩展 供应商调用示例(脚本片段) - 上下文模板参数 => API 模板 。 模板片段 crud 管好就行。