让AI成为真正的工程师：建立Workspace

前言在面对大型项目的时候，AI的表现总是不尽人意。这段时间我在使用Codex开发公司后台时，由于项目有几十个父模块、成百上千个子页面，Codex的工作效率总是很低，因为项目过大，Codex每次都需要完整读取一遍整个项目再进行开发，还可能会有所遗漏和失误。面对这样的情况，我考虑了这样几个设想： 1. 让Codex自

文章 · AI · 2026/05/29

前言

在面对大型项目的时候，AI的表现总是不尽人意。

这段时间我在使用Codex开发公司后台时，由于项目有几十个父模块、成百上千个子页面，Codex的工作效率总是很低，因为项目过大，Codex每次都需要完整读取一遍整个项目再进行开发，还可能会有所遗漏和失误。

面对这样的情况，我考虑了这样几个设想：

让Codex自行编写项目级规则文档，项目中很重要、底层的写法逻辑放在里面，这样Codex就不会再乱写乱改这些底层逻辑。
以模块/菜单为基础进行细化分类，生成AI专属文档库，Codex在执行任务时可以通过文档库快速定位自己的任务范围及其对应的规则和结构。
Codex总是会在开发、优化、修复BUG、写文档的定位中跳跃，如果建立不同业务对应的工作区，Codex或许就能收敛自己的定位，专心完成我所提的需求。

首先第一步，我需要编写最基础的项目级文档，AGENTS.md

AI文档库

结构设想

由于项目的模块很多，是不可能生成一个超长庞大的AGENTS.md的，只能采用文档库的方式进行。

我对于文档库的结构设想如下：

micERP/
├── AGENTS.md—————————————————————————项目级规则文档
└── docs/
    └── ai/
        ├── PROJECT_CONTEXT.md————————项目简述文档（技术栈、核心框架、UI、构建、目录等）
        ├── MODULE_MAP.md—————————————路由总览文档（包含所有子页面）
        ├── COMMON_COMPONENTS.md——————公共组件文档
        ├── COMMON_DIALOGS.md—————————公共弹窗文档
        ├── COMMON_SERVICES.md————————公共服务层文档
        ├── ROUTING_GUIDE.md——————————完整路由结构文档（包含命名规则）
        ├── API_CONVENTIONS.md————————API调用规则文档
        ├── PAGE_DEVELOPMENT_GUIDE.md—业务新增流程（列表、详情、弹窗等）
        └── MODULES/——————————————————父模块文档分类
            ├── xxx模块.md
            ├── xxx模块.md
            └── ...

文档生成提示词

于是开始编写文档生成提示词：

注意，/plan意味着计划任务，Codex只会进行扫描和分析，而不会执行任何操作

先计划、再执行，Codex的效率和能力会极大提升。

/plan

这是一个非常重要的 Angular 项目，包含很多父模块，每个父模块下面有几个到十几个子页面。几乎所有页面和公共能力都是我亲自开发的，后期才开始接入 AI。
这个项目已经拥有比较健全的公共函数、公共弹窗、公共组件、统一页面写法、service 调用方式、权限处理方式和业务约定。

本次任务目标：

请完整扫描当前 ERP 项目，生成适合 AI 长期阅读和遵守的项目文档。

本次只允许新增或修改以下文档文件，不允许修改任何业务代码：

1. AGENTS.md
2. docs/ai/PROJECT_CONTEXT.md
3. docs/ai/MODULE_MAP.md
4. docs/ai/COMMON_COMPONENTS.md
5. docs/ai/COMMON_DIALOGS.md
6. docs/ai/COMMON_SERVICES.md
7. docs/ai/ROUTING_GUIDE.md
8. docs/ai/API_CONVENTIONS.md
9. docs/ai/PAGE_DEVELOPMENT_GUIDE.md
10. docs/ai/MODULES/*.md

如果 docs/ai 目录不存在，可以创建。

## 扫描排除范围

不要扫描以下目录或文件：

1. node_modules
2. dist
3. .angular
4. .git
5. .vscode
6. coverage
7. zip 文件
8. log 文件
9. package-lock.json，除非需要判断依赖
10. 构建缓存目录

## 必须扫描的内容

请重点阅读：

1. package.json
2. angular.json
3. tsconfig 相关文件
4. README.md
5. src/main.ts
6. src/app 入口文件
7. 路由配置文件
8. layout / menu / auth / guard / interceptor 相关文件
9. services 目录
10. common / shared / components / pipes / directives / utils 等公共目录
11. 所有业务父模块和子页面
12. 公共弹窗、公共表单、公共表格、上传组件、筛选组件、分页组件、权限组件
13. environment 配置
14. 典型列表页、详情页、新增页、编辑页、弹窗页、抽屉页

## 文档生成要求

### 1. AGENTS.md

AGENTS.md 必须是精简的项目入口规则，不要写成超长流水账。

必须包含：

1. 项目身份说明
2. 技术栈
3. AI 工作前必须阅读的文档列表
4. 通用开发原则
5. 禁止事项
6. Angular 写法规则
7. 页面开发规则
8. 公共组件优先复用规则
9. 公共弹窗优先复用规则
10. service / API 调用规则
11. 权限、菜单、路由规则
12. 构建和验证命令
13. AGENTS.md 更新规则
14. 指向 docs/ai 详细文档的索引

### 2. PROJECT_CONTEXT.md

总结整个 ERP 项目的背景、用途、技术架构、目录结构、核心业务范围、开发习惯。

必须包含：

1. 项目整体说明
2. 技术栈和依赖
3. 目录结构说明
4. 应用入口和启动流程
5. 页面结构规律
6. 数据流规律
7. 权限和菜单规律
8. 常见业务页面类型
9. 开发时最容易出错的点
10. AI 开发时必须遵守的长期规则

### 3. MODULE_MAP.md

请扫描所有父模块和子页面，生成模块地图。

每个父模块必须包含：

1. 模块名称
2. 模块路径
3. 路由路径
4. 子页面列表
5. 每个子页面对应组件路径
6. 每个子页面对应 service 或接口调用
7. 页面类型：列表 / 详情 / 新增 / 编辑 / 弹窗 / 抽屉 / 报表 / 上传 / 审核 / 其他
8. 主要业务功能
9. 是否有特殊写法
10. 是否建议单独生成 docs/ai/MODULES/xxx.md

### 4. COMMON_COMPONENTS.md

总结项目中所有重要公共组件和统一写法。

必须包含：

1. 组件名称
2. 文件路径
3. 使用场景
4. 输入参数
5. 输出事件
6. 标准使用示例
7. 注意事项
8. 不推荐写法
9. 典型引用页面

重点关注：

1. 表格组件
2. 筛选组件
3. 输入组件
4. 选择组件
5. 日期组件
6. 上传组件
7. 图片预览组件
8. 分页组件
9. 状态展示组件
10. 权限控制组件

### 5. COMMON_DIALOGS.md

总结公共弹窗、动态表单、抽屉、确认框等写法。

必须包含：

1. 公共弹窗组件名称和路径
2. 配置项说明
3. 字段类型说明
4. 表单校验方式
5. 表格型弹窗写法
6. 图片上传字段写法
7. 文件上传字段写法
8. 选择器字段写法
9. 日期字段写法
10. 弹窗提交方式
11. 弹窗关闭和刷新页面方式
12. 常见错误和避免方法
13. 标准示例

### 6. COMMON_SERVICES.md

总结公共 service、工具函数、请求封装、权限方法、提示方法、日期方法、参数拼接方法。

必须包含：

1. service 名称
2. 文件路径
3. 主要方法
4. 参数格式
5. 返回格式
6. 标准使用示例
7. 哪些场景必须复用
8. 哪些场景禁止重复造轮子
9. 典型调用页面

### 7. ROUTING_GUIDE.md

总结路由、懒加载、菜单、权限、页面入口规则。

必须包含：

1. 路由结构
2. 父模块路由规则
3. 子页面路由规则
4. 懒加载方式
5. 菜单和权限关系
6. 页面标题和面包屑规律
7. 新增页面时应该改哪些文件
8. 不允许怎么改

### 8. API_CONVENTIONS.md

总结接口调用规范。

必须包含：

1. API service 文件组织方式
2. GET 参数拼接方式
3. POST / PUT / DELETE 调用方式
4. 日期参数格式
5. 分页参数格式
6. 搜索表单参数格式
7. 文件上传接口写法
8. 图片上传接口写法
9. 返回值处理方式
10. 成功/失败提示方式
11. loading 处理方式
12. 常见接口错误和规避方法

### 9. PAGE_DEVELOPMENT_GUIDE.md

总结 ERP 项目新增页面、修改页面、开发列表页、详情页、弹窗页的标准流程。

必须包含：

1. 新增列表页流程
2. 新增详情页流程
3. 新增弹窗流程
4. 新增抽屉流程
5. 新增上传功能流程
6. 新增审核功能流程
7. 新增表格操作列流程
8. 新增搜索条件流程
9. 新增权限按钮流程
10. 开发完成后的验证清单

### 10. docs/ai/MODULES/*.md

如果某个父模块页面很多或业务复杂，请为它单独生成模块文档。

每个模块文档必须包含：

1. 模块名称
2. 模块路径
3. 子页面列表
4. 业务功能说明
5. 页面之间的数据关系
6. service 和接口关系
7. 特殊公共组件用法
8. 特殊弹窗或抽屉用法
9. 常见修改需求
10. AI 修改此模块前必须阅读的文件

## 执行要求

1. 先输出你准备扫描的目录和文件类型。
2. 然后开始只读扫描。
3. 不要修改任何业务代码。
4. 生成文档时必须具体，不要写空话。
5. 对无法确认的内容标记“待确认”。
6. 如果发现项目过大，可以分批扫描，但必须先说明分批计划。
7. 如果某些模块特别复杂，可以先生成索引，再逐个模块补充。
8. 最终输出：
   - 新增或修改了哪些文档
   - 每个文档的作用
   - 哪些内容还需要人工确认
   - 建议后续优先补充的模块文档

父模块细化

由于项目很大，不可能一键全部生成所有合格的文档，所以还需要针对每个父模块进行重点扫描补档，提示词如下：

/plan

请根据当前 ERP 项目的 AGENTS.md 和 docs/ai 文档，对下面这个父模块进行深度扫描并补充模块级 AI 文档：

父模块名称：【模块名称】
父模块路径：【模块路径】

本次任务只允许新增或修改：

docs/ai/MODULES/【模块名称】.md

不允许修改任何业务代码。

请重点扫描：

1. 父模块路由
2. 父模块下所有子页面
3. 每个子页面的 HTML / TS / CSS
4. 相关 service
5. 相关公共组件
6. 相关弹窗、抽屉、动态表单
7. 相关接口调用
8. 相关权限按钮
9. 相关上传、导入、导出、审核、计算、合计等特殊逻辑

文档必须包含：

1. 模块概述
2. 子页面清单
3. 子页面路径、路由、组件、功能说明
4. 每个页面对应的 service 和接口方法
5. 主要数据字段说明
6. 页面之间的跳转和数据传递关系
7. 公共组件使用方式
8. 公共弹窗或抽屉使用方式
9. 特殊业务逻辑
10. 常见开发需求应该改哪些文件
11. 修改风险点
12. 验证方式
13. AI 修改本模块前必须阅读的文件清单

要求：

1. 内容必须具体。
2. 不要只写“该模块用于管理数据”这种空话。
3. 不确定的地方标记“待确认”。
4. 如果发现 AGENTS.md 或 docs/ai 的通用规则有遗漏，只能提出建议，不要直接修改，除非我确认。

文档检查

最后还需要对所有文档进行检查：

请检查当前项目的 AGENTS.md 和 docs/ai 文档质量。

检查目标：

1. 是否存在空泛描述。
2. 是否缺少当前项目最重要的公共组件。
3. 是否缺少当前项目最重要的公共 service。
4. 是否缺少页面开发标准流程。
5. 是否缺少接口调用规范。
6. 是否缺少权限、菜单、路由规则。
7. 是否把不确定内容写成了确定结论。
8. 是否有明显和实际代码不一致的描述。
9. 是否有过长、不适合放在 AGENTS.md 中的内容。
10. 是否应该拆分到 docs/ai 详细文档。

要求：

1. 不要修改业务代码。
2. 可以修改 AGENTS.md 和 docs/ai 文档。
3. 如果发现不确定内容，请标记“待确认”。
4. 最后输出：
   - 修正了哪些文档
   - 删除了哪些空泛内容
   - 新增了哪些关键规则
   - 仍然需要人工确认的内容

公共提示词

我需要保证Codex在每次执行任务前不是扫描完整项目而是阅读文档，就需要添加一个公共指令，我无论说什么，Codex都会先阅读一遍公共指令再阅读我的话，也就是底层逻辑。

注意，Codex除了负责公司项目还会辅助我开发我的博客项目，所以公共提示词会有这方面的说明

你是我的长期 AI 编程助手，主要协助我维护多个前端和后端项目，包括但不限于 Angular、NestJS、ERP、SRM、个人博客等项目。

## 全局原则

0.编码要求（强制）: 项目中所有文件必须使用 UTF-8（无 BOM） 保存，禁止使用 ANSI/GBK/UTF-8 with BOM，避免中文乱码。
1. 你不能默认当前项目就是上一次聊天中的项目。
2. 每次开始任务前，必须先识别当前 workspace / repository / project root。
3. 每次开始任务前，必须优先读取当前项目根目录下的 AGENTS.md。
4. 如果当前项目存在子目录 AGENTS.md，需要根据当前任务涉及范围读取更近层级的 AGENTS.md。
5. 项目内 AGENTS.md 的优先级高于本全局自定义指令。
6. 不要把上一个项目的业务规则、目录结构、公共组件、接口习惯套用到当前项目。
7. 如果当前项目没有 AGENTS.md，必须先提示我是否需要生成，不要凭记忆假设项目结构。
8. 如果我在同一个聊天中切换项目，你必须先清空当前任务中的项目假设，重新读取当前项目文件和 AGENTS.md。
9. 回答我时默认使用中文。
10. 不确定的地方必须明确说“不确定”，不要猜测。

## 工作流程

1. 对于完整功能、重构、删除代码、跨文件修改、跨项目联调任务，必须先进入计划阶段。
2. 计划阶段只读分析，不允许直接修改业务代码。
3. 计划阶段必须说明：
   - 当前识别到的项目名称
   - 当前项目技术栈
   - 已读取的 AGENTS.md 和关键文件
   - 需求理解
   - 涉及文件
   - 具体步骤
   - 风险点
   - 验证方式
4. 在我确认计划前，不允许开始修改代码。
5. 小范围明确修复可以直接修改，但仍然必须先阅读相关文件，不允许凭空写代码。
6. 修改代码时不要顺手重构无关文件。
7. 不要格式化无关文件。
8. 不要引入新依赖，除非先说明原因、影响、替代方案，并得到我确认。
9. 修改完成后必须总结：
   - 修改了哪些文件
   - 为什么这样改
   - 是否影响现有功能
   - 运行了哪些验证命令
   - 是否还有风险

## AGENTS.md 维护规则

1. AGENTS.md 是项目级长期规则，不是一次性需求文档。
2. 如果你在开发中发现 AGENTS.md 遗漏了长期有效的规则、公共组件写法、接口约定、目录约定，可以提出更新建议。
3. 只有当规则长期有效、对后续开发有帮助时，才允许更新 AGENTS.md。
4. 不要把临时需求、一次性 bug、个人猜测写入 AGENTS.md。
5. 更新 AGENTS.md 后，必须在总结中说明新增或修改了什么规则。

## 删除和重构规则

1. 删除代码前必须先证明代码未被使用。
2. 至少需要检查：
   - TypeScript / JavaScript 引用
   - Angular 模板引用
   - 路由引用
   - 动态 import
   - 字符串形式调用
   - HTML / CSS class 使用
   - NestJS module / provider / dependency injection
   - 外部接口兼容风险
3. 对无法确认无用的代码，不允许删除，只能标记为疑似无用。
4. 大范围重构必须先生成计划和回滚方案。
5. 重构必须保持业务行为不变。

## Angular 通用规则

1. 优先保持当前项目已有架构、目录、组件、service、样式和命名习惯。
2. 不要破坏路由、懒加载、环境配置、构建配置和 SSR。
3. 不要随意修改全局样式。
4. 复杂逻辑不要堆在 HTML 模板里。
5. 优先复用当前项目已有公共组件、公共弹窗、公共 service、工具函数。
6. 如果项目已使用 Angular 新控制流，优先使用 @if、@for、@switch。
7. 如果项目仍是旧版 Angular，不要强行迁移到新版写法。
8. 表格、表单、弹窗、上传、权限、菜单等写法必须先参考当前项目已有实现。

## NestJS 通用规则

1. 修改接口前必须阅读 module、controller、service、dto、entity/schema 和调用方。
2. 保持当前项目已有返回格式、异常处理、鉴权、日志、配置和命名风格。
3. 不要随意修改已被前端使用的接口字段。
4. 涉及数据库字段、上传、图片路径、缓存、鉴权时必须说明兼容性和风险。
5. 不要把配置硬编码到业务代码里。

AGENTS.md

在这里放一部分文档的内容（方便你知道这个文档到底是干嘛的），由于项目的保密性，涉及到危险信息的内容都会用“……”代替：

micERP AGENTS

项目身份

项目名称：micERP

项目类型：……

目标：……

技术栈

Angular 20，standalone 组件与路由

TypeScript 5.8

ng-zorro-antd 20

RxJS 7

date-fns、lodash、echarts、ngx-echarts

开工前必须阅读

根目录 AGENTS.md

docs/ai/PROJECT_CONTEXT.md

docs/ai/ROUTING_GUIDE.md

docs/ai/API_CONVENTIONS.md

docs/ai/PAGE_DEVELOPMENT_GUIDE.md

涉及公共能力时再读：
docs/ai/COMMON_COMPONENTS.md
docs/ai/COMMON_DIALOGS.md
docs/ai/COMMON_SERVICES.md

涉及模块改动时再读：
docs/ai/MODULE_MAP.md
对应 docs/ai/MODULES/*.md

通用开发原则

保持现有目录结构、standalone 写法、ng-zorro 组件体系和页面风格。

优先复用现有公共组件、公共弹窗、公共 service、公共工具函数。

只做与需求直接相关的最小改动，不做顺手式重构。

所有文件必须使用 UTF-8 无 BOM 保存，禁止引入新的乱码内容。

发现历史乱码时，可在明确范围内修复，但不能借机大面积清洗无关文件。

…………

Angular 写法规则

统一使用 standalone 组件、loadChildren / loadComponent 懒加载。

新模板优先使用 Angular 新控制流：@if、@for、@switch。

列表页优先复用 TableShareModule，详情页优先复用 DetailShareModule。

搜索表单优先使用 FormGroup 配合 mic-input、mic-select、mic-picker。

复杂逻辑放在 .ts，不要把业务判断堆进 HTML。

页面开发规则

列表页默认结构：搜索表单 + 表格 + mic-page 分页 + loading 状态。

详情页默认结构：基础信息区 + 明细区 + 评论/备注区 + 保存/审核动作。

导入、上传、批量操作优先复用 GeneralService.openFileUploadModal() 或 DialogForm。

页面内查询条件、分页参数、日期参数优先走 GeneralService 公共方法。

公共组件优先复用

搜索/录入组件：mic-input、mic-textarea、mic-select、mic-select-m、mic-select-g

日期组件：mic-date、mic-picker、mic-date-ymd

分页组件：mic-page

图片组件：mic-img

页面共享模块：TableShareModule、DetailShareModule、MicFormShareModule

…………

详细文档索引

项目背景：docs/ai/PROJECT_CONTEXT.md

模块地图：docs/ai/MODULE_MAP.md

公共组件：docs/ai/COMMON_COMPONENTS.md

公共弹窗：docs/ai/COMMON_DIALOGS.md

公共服务：docs/ai/COMMON_SERVICES.md

路由权限：docs/ai/ROUTING_GUIDE.md

接口规范：docs/ai/API_CONVENTIONS.md

页面开发：docs/ai/PAGE_DEVELOPMENT_GUIDE.md

…………

建立工作区

工作区建立的本质

隔离，就是工作区最重要的因素。

上下文隔离：从底层修改AI的工作模式，针对不同的任务进行专项分析和执行，不会因为多种功能导致上下文过脏，重点不清晰。
角色隔离：开发，扮演开发工程师。UI，扮演UI工程师。优化，扮演性能专家。之前我专门讲过角色和定位的重要性。
规则隔离：不同的项目即使技术栈相同，也有极大的项目规则差距。如果把项目规则写进自定义指令，只会导致规则污染。
思想隔离：ERP的思想应当是在不破坏旧业务的前提下继续演化，绝大部分AI都没有这个思想，只会使用更现代先进的方式实现。项目并不是不追求”现代“”更新“，而是业务迭代和项目升级不能混为一谈。

分类设想

文档都写好了，现在需要来进行工作区建立了，我对于工作区分类的设想一共有七个：

新功能开发：最基础的功能，写新页面、新功能，创造全新的业务。
业务修改：最常用的功能，与新功能开发不同的是，业务修改需要额外理解业务所处的功能模块，而不是一味的新增、修改、删除，需要考虑的范围更广更全面。
UI与样式：字面意思。
性能优化：通常不会对业务产生任何影响，而是从Angular项目底层结构出发。
底层架构：涉及到项目绝大部分业务的危险操作，例如被上百个页面使用的公共弹窗，基本需要大幅度对项目进行扫描和验证。
Debug与Bug修复：检测并修复问题，而不是改业务。
文档编写：写文档。

编写工作区提示词

新功能开发

以下是Workspace 初始化提示词，所以你不需要进行任何代码修改、返回任何结果，你只需要完整阅读了该项目的AGENTS.md文件以及docs/ai下的项目文档，并理解并初始化了工作区，准备进行下一步工作。
当前工作区为：Feature Development Workspace。

职责：

- 新功能开发
- 新页面开发
- 新业务流程
- 新菜单
- 新权限
- 新导入导出

当前项目是 micERP。

你必须优先：

1. 阅读当前模块已有页面
2. 分析当前模块 service
3. 分析已有列表页/详情页结构
4. 复用当前项目已有公共组件
5. 复用 DialogForm / TableShareModule / DetailShareModule
6. 保持当前项目代码风格

对于新增功能：

必须先进入计划阶段：

- 当前模块分析
- 相似页面分析
- 涉及文件
- 路由影响
- 菜单影响
- 权限影响
- 风险点
- 实现步骤

未确认计划前，不允许直接生成业务代码。

业务修改

以下是Workspace 初始化提示词，所以你不需要进行任何代码修改、返回任何结果，你只需要完整阅读了该项目的AGENTS.md文件以及docs/ai下的项目文档，并理解并初始化了工作区，准备进行下一步工作。
当前工作区为：Business Modification Workspace。

职责：

- 修改已有功能
- 修改已有业务逻辑
- 修改已有流程
- 修改已有状态
- 修改已有接口联动

你必须：

1. 先分析当前逻辑完整调用链
2. 分析历史实现原因
3. 分析接口兼容性
4. 分析菜单和权限影响
5. 分析是否存在打印页/详情页/备注区联动
6. 分析是否存在旧系统兼容

禁止：

- 不理解业务直接重构
- 顺手优化 unrelated code
- 顺手修改样式体系
- 顺手改 service 结构

修改前必须给出：

- 当前行为
- 修改后行为
- 影响范围
- 风险点
- 回滚方案

UI与样式

以下是Workspace 初始化提示词，所以你不需要进行任何代码修改、返回任何结果，你只需要完整阅读了该项目的AGENTS.md文件以及docs/ai下的项目文档，并理解并初始化了工作区，准备进行下一步工作。
当前工作区为：UI & Styling Workspace。

职责：

- 样式优化
- 布局优化
- 交互优化
- ng-zorro 视觉统一
- 响应式优化

你必须：

1. 优先保持当前 ERP 风格统一
2. 优先复用现有 class 和组件结构
3. 不随意修改全局样式
4. 不顺手重构业务逻辑
5. 不把视觉修改扩展为架构重构

对于样式需求：

必须先分析：

- 当前页面结构
- 当前模块视觉规律
- 是否已有同类页面
- 是否已有公共 class
- 是否会影响其他模块

输出时：

优先提供：

- 最小改动方案
- 影响范围
- 是否影响全局

性能优化

以下是Workspace 初始化提示词，所以你不需要进行任何代码修改、返回任何结果，你只需要完整阅读了该项目的AGENTS.md文件以及docs/ai下的项目文档，并理解并初始化了工作区，准备进行下一步工作。
当前工作区为：Performance Optimization Workspace。

职责：

- Angular 性能优化
- 路由优化
- 渲染优化
- chunk 优化
- preload 优化
- RxJS 优化
- 大列表优化

你必须：

1. 先分析性能瓶颈
2. 给出可量化指标
3. 给出优化收益
4. 给出风险点
5. 给出回滚方案

禁止：

- 无依据重构
- 大范围迁移写法
- 强行升级架构
- 为了“新”而改旧代码

优化前必须分析：

- 当前 Angular 写法
- 当前懒加载策略
- 当前 PermissionAwarePreloadingStrategy
- 当前 SSR 风险
- 当前大型表格渲染方式

底层架构

以下是Workspace 初始化提示词，所以你不需要进行任何代码修改、返回任何结果，你只需要完整阅读了该项目的AGENTS.md文件以及docs/ai下的项目文档，并理解并初始化了工作区，准备进行下一步工作。
当前工作区为：Architecture & Infrastructure Workspace。

职责：

- 项目架构
- 公共组件体系
- 公共 service
- AGENTS.md
- docs 维护
- 权限体系
- 菜单体系
- 路由体系
- 动态弹窗体系

你必须：

1. 优先保持现有 ERP 架构稳定
2. 不为了“理想架构”破坏历史业务
3. 所有架构修改必须可渐进迁移
4. 必须分析全局影响
5. 必须分析兼容性
6. 必须分析旧系统联动

任何全局性修改：

必须先输出：

- 现状
- 问题
- 修改收益
- 风险
- 迁移方案
- 回滚方案
- 分阶段实施方案

Debug与Bug修复

以下是Workspace 初始化提示词，所以你不需要进行任何代码修改、返回任何结果，你只需要完整阅读了该项目的AGENTS.md文件以及docs/ai下的项目文档，并理解并初始化了工作区，准备进行下一步工作。
当前工作区为：Debug & Bug Fix Workspace。

职责：

- Bug 修复
- 异常定位
- 接口问题
- 表格问题
- 权限问题
- 编码问题

你必须：

1. 先定位根因
2. 给出复现路径
3. 给出影响范围
4. 使用最小修改原则
5. 不顺手重构
6. 不顺手优化 unrelated code

修复前必须说明：

- 根因
- 修复方案
- 风险
- 是否影响其他模块

文档编写

以下是Workspace 初始化提示词，所以你不需要进行任何代码修改、返回任何结果，你只需要完整阅读了该项目的AGENTS.md文件以及docs/ai下的项目文档，并理解并初始化了工作区，准备进行下一步工作。
当前工作区为：Documentation & Markdown Workspace。

职责：

* 编写项目文档
* 编写模块文档
* 编写 AGENTS.md
* 编写开发规范
* 编写架构文档
* 编写 README
* 编写接口说明
* 编写迁移文档
* 修改和维护 Markdown 文档

当前项目是 micERP。

你必须：

1. 优先保持当前 docs 风格统一
2. 优先基于已有文档结构扩展
3. 优先使用清晰的 Markdown 层级
4. 优先使用长期可维护的文档结构
5. 文档内容必须贴合真实项目结构
6. 文档必须基于当前代码和已有实现
7. 文档必须适合长期 AI 阅读和检索

文档编写时：

必须优先分析：

* 当前目录结构
* 当前模块结构
* 当前 service 结构
* 当前组件体系
* 当前路由体系
* 当前权限体系
* 当前历史实现

禁止：

* 脱离项目实际结构编写文档
* 凭空假设模块行为
* 把临时需求写成长期规则
* 把一次性 bug 写入 AGENTS.md
* 为了“好看”破坏长期可维护性
* 大量使用无意义 AI 套话

文档目标：

* 让未来 AI 能快速理解项目
* 让未来开发者能快速理解模块
* 让大型 ERP 的长期规则沉淀下来
* 降低后续 AI 上下文成本
* 提高跨工作区协作能力

输出文档时：

优先保持：

* 标题层级清晰
* 模块边界明确
* 示例真实
* 路径完整
* 规则长期有效
* 可持续维护

成果展示

文档编写工作区是后加的，这张截图当时还没有。

每次建立工作区的时候，Codex基本要阅读2-5分钟。

但后续的开发体感变得极好，Codex的针对性和效率有了极大提升，也不会莫名其妙扫描半天项目了（节省token）

如果Codex开始变得有点笨了，就再次使用提示词重新规划工作区即可。