企业官网建设流程全解析

codex 团队协作开发流程

• • git 管理版本，以及随时回退当前版本
  • Agents.md 项目与全局规约
  • 理想+漂亮+准确计算的 数据看板
  • 信息图
  • Goal 长期任务模式
  • 辅助插件
  • codex 多人协作开发 · 真实项目流程
  • • 单工作树
    • 多工作树
    • 内化成选择题 skill：GitLab 安全提交向导
  • 文档驱动开发 + 测试驱动开发，组合工作流 skill

git 管理版本，以及随时回退当前版本

输入：把当前项目保存成一个版本，只做本地提交，不要推送

先保存，避免改着改着坏了，不能恢复。

git 能回退某版本代码，但不能回退到数据库数据。

Agents.md 项目与全局规约

Agents.md自定义内容：

1.修改代码时优先保持项目现有结构，不要过度设计2.不要主动引入新依赖，除非确实必要3.不要自动执行 git push4.只有我明确要求时，才提交 commit5.改完代码后说明改了哪些文件、为什么改、如何验证6.遇到不确定的地方，先基于现有代码做最小改动7.采用测试驱动开发+文档驱动开发8.在gitcommit~前，务必读取 git-commit-convention.md

git-commit-convention.md：

#AI 提交信息生成规范##0.前置分支强制校验模块 ###0.1变量填写位置 【当前分支填写处】current_branch=____________>使用时请在横线位置填入真实Git分支名称，为空代表无有效分支 ###0.2执行优先级 触发生成提交信息、执行提交操作前，**第一步必须读取上方current_branch分支变量完成校验**，未校验禁止执行后续任何代码变更解析、commit文案生成逻辑。 ###0.3分支校验判定规则1.❌ 禁止直接提交保护分支（匹配即校验失败）：main、master、prod、release2.✅ 允许提交的合规分支类型（满足任意一条即校验通过）：-前缀分支：feature/*、bugfix/*、hotfix/*、dev/*、test/* - 人名分支：以大写英文字母开头的人物姓名命名分支（例：YSS、SXH、ZRL） 3. 异常情况：current_branch 空白/乱码无效字符，判定校验失败，终止全部流程。 ### 0.4 校验固定输出文案 - 校验通过：分支校验完成，当前分支：{填入的分支名}，符合提交规范，开始解析代码变更 - 校验失败：分支校验不通过，当前分支：{填入的分支名}，该分支不允许直接提交代码，请切换至规范开发分支后重试 ## 1. 触发条件 用户下达「生成提交信息」「执行提交」指令时，优先执行0章节分支校验，校验通过后，严格遵循本规范输出提交文案。 ## 2. 变更读取规则 1. 依据 `git diff --staged` / `git diff` 解析全部待提交代码变更内容； 2. 变更文件数量大于5个时，先汇总所有文件路径、划定改动影响范围，再生成规范提交信息。 ## 3. 强制标准提交结构（核心） 仅输出符合下述模板的单条或多条提交记录，仅正文提及文件名称时使用代码块包裹，整体提交文本不额外套代码块： <type>(<scope>): <subject> [可选补充正文body，详细说明改动逻辑] [可选脚注footer，关联工单/标注破坏性变更] ### 3.1 type 改动类型（必填，严格单选） 仅选用下表词汇，禁止使用 update、modify、change 等模糊笼统描述： - feat：新增用户侧功能、前端页面、对外接口等用户可见变更 - fix：修复线上、测试环境存在的业务缺陷、逻辑bug - docs：仅调整项目文档、代码注释、README、Wiki说明文本 - style：纯格式调整，不改动业务逻辑（缩进、空格、分号、代码格式化） - refactor：代码重构优化，无bug修复、无新增功能（变量重命名、公共方法抽取、冗余代码删减） - perf：专项性能优化，提升执行速度、降低内存/带宽占用 - test：新增、调整单元测试、集成测试、测试用例 - build：调整构建配置、第三方依赖包、项目打包脚本（Vite/Webpack/pip/npm配置） - ci：修改自动化流水线配置（GitHub Actions、GitLab CI、Jenkins等） - chore：杂项配置调整，不涉及业务源码、测试文件（更新.gitignore、版本号、配置文件） - revert：回滚历史某次提交记录 ### 3.2 scope 作用域（选填） 1. 优先填写改动对应模块名、组件名、核心文件名（不带文件后缀）； 2. 多模块无关改动可省略scope，或使用 `*` 作为通用标识。 ### 3.3 subject 主题（必填，强约束规则） 1. 统一使用中文撰写，适配国内团队协作规范； 2. 采用动词开头祈使句式，使用原形动词，禁止后缀「了」「过」； 3. 全文无末尾句号、顿号收尾； 4. 文字长度上限50个中文字符，简洁直白，不写冗余概括。 ### 3.4 body 正文说明（选填） 1. 核心说明改动原因、业务背景，不重复复述代码改动内容； 2. 对比旧逻辑缺陷、本次优化带来的收益； 3. 微小简单改动（文字修正、空格调整）可省略正文； 4. 单行文字长度不超过72个中文字符。 ### 3.5 footer 脚注（选填） 1. 破坏性兼容变更：接口/数据表结构/函数入参发生不兼容改动时，type后缀添加 `!`，脚注首行固定 `BREAKING CHANGE: 变更详细描述`； 2. 关联工单需求：绑定GitLab Issue、TAPD需求单，格式为 `Closes #单号`（修复对应需求）、`Refs #单号`（关联参考需求）； 3. 禁止添加协同作者字段（Co-Authored-By 相关内容一律不出现）。 ## 4. 变更拆分逻辑规则 读取多文件diff后，按以下逻辑拆分/合并提交记录： 1. 合并规则：多文件归属同一业务逻辑单元（如业务逻辑文件+对应测试文件），统一合并为单条提交； 2. 拆分规则：多组文件分属完全独立、无关联改动（如A模块bug修复 + B模块依赖升级），必须拆分为多条独立提交，按改动主次顺序依次输出； 3. type快速判定规则： - 删减代码、无新增功能：refactor / fix - 新增对外接口、页面功能：feat - 仅修改CI流水线配置文件：ci - 修改package.json版本、.gitignore：chore 4. 破坏性变更识别：函数名称、接口请求地址、入参出参结构、数据表字段调整，必须标记 `!` 并补充BREAKING CHANGE说明。 ## 5. 标准输出示例 ### 示例1：人名分支校验通过完整输出 【当前分支填写处】current_branch = ZhangSan 分支校验完成，当前分支：ZhangSan，符合提交规范，开始解析代码变更 fix(登录): 修复手机号含首尾空格时校验拦截问题 重写手机号正则校验逻辑，增加首尾空格自动剔除处理，解决粘贴手机号误带空格无法提交的问题。 Closes #1024 ### 示例2：前缀开发分支校验通过 【当前分支填写处】current_branch = bugfix/login-verify 分支校验完成，当前分支：bugfix/login-verify，符合提交规范，开始解析代码变更 ### 示例3：保护分支校验失败输出 【当前分支填写处】current_branch = main 分支校验不通过，当前分支：main，该分支不允许直接提交代码，请切换至规范开发分支后重试 ### 示例4：多组无关改动拆分多条提交 feat(报表): 新增Excel报表导出接口 新增/api/report/export接口，支持自定义日期范围导出CSV业务数据。 --- feat(用户): 头像上传前增加图片自动压缩逻辑 前端检测超过2MB头像文件，自动压缩至1080*1080分辨率，减少服务器存储占用。 ### 示例5：破坏性不兼容变更 refactor!(数据库): User表ID字段由int整型改为UUID格式 BREAKING CHANGE：所有调用用户ID的外部微服务需同步调整数据存储与解析逻辑。 ## 6. 禁止行为约束 ❌ 跳过【当前分支填写处】的current_branch校验步骤，直接生成提交信息； ❌ 分支校验失败后仍产出commit提交文案； ❌ subject使用「修改代码」「更新文件」等无价值笼统描述； ❌ 格式化修复（style类改动）与业务功能、bug修复合并为同一条提交，需分开拆分； ❌ 未读取diff、未分析代码改动凭空编造提交信息； ❌ 提交信息内添加各类表情符号（无团队特殊约定时）； ❌ 在主题括号内标注开发作者姓名； ❌ 输出Co-Authored-By等协同作者相关备注内容； ❌ 忽略空白current_branch变量直接执行提交流程。

理想+漂亮+准确计算的 数据看板

设计流程：要让codex读取所有文件资料，再给出一些关键指标，再画图，后修订。

启动规划模式：1.先读所有资料，确认数据之间对得上，如多少字段、多少行数、数据干净与否、数据质量和表、表格和表格之间对得上2.基于对得上的关系，挖掘出有价值的分析3.我最关注的是 总xx、总xx、各个xx，你也可以分析其他指标4.给出一份看板方案：放哪些关键指标，配哪些图表

验算：

1.先不执行方案，需要验证方案的数据正确性，按你给出的方案，把里面要用的关键指标都算出来2.指标顺序按照计算复查程度从易到难排序3.每个指标给出：指标名称、使用来源、字段、计算公式、人工验证方法、当前结果

信息图

codex 使用Image Gen skill。

纯图像生成：

1.使用纯图像模型生成图像，不要代码生成、SVG2.做一张中文信息图，中文需清晰且不变形，16:9适配电脑查看3.主题是4.风格现代、清爽、专业

代码生成：

1.使用代码生成图像2.做一张中文信息图，中文需清晰且不变形，16:9适配电脑查看3.主题是4.风格现代、清爽、专业

混合生成：

使用混合生成：1.图像模型生成背景或者插画2.代码负责文字和排版3.文字要与AI生成的图片配合协调4.做一张中文信息图，16:9适合电脑看，主题是5.风格要现代、清爽、专业6.中文文字需要清晰且不变形

ppt生成：

• pptx 技能：Presentations

1.先定主线：今年围绕什么目标做了哪些事，带来了什么结果，沉淀了什么方法，明年准备怎么提升？2.把内容提炼成PPT成果表达：从原始叙事中提炼目标、动作、结果、影响，用数据和结论表达价值3.先做页纲：拆成每一页的标题、核心信息、数据、页面表达方式4.确定视觉风格：有公司规定模版就用公司规定，没有就找找好看的模版（默认模版是 纯白+不怎么好看）5.生成 PPTX：每页只讲一个重点，少放大段文字，多用数字、表格、对比与简短结论6.逐页检查：生成后必须检查：文字有没有挤、有没有重叠、表格是否可读、数据有没有前后不一致、有没有模版占用文字残留7.多轮优化：第一版看结构，结构没问题，再优化其他维度

Goal 长期任务模式

Goal 模式：长期任务模式。

• 适合多约束、多工具配合，需要反复检查的任务，输出完整交付的长期任务。
• 围绕目标持续推进直到完成
• 按验收标准逐项确认是否达标
• 目标不清晰导致执行方向不稳

我的codex是 0.154.0 版本，直接输入，就能启动：

/goal 修复当前项目中的bug

如果找不到这个命令，那需要自己配置：

• codex 版本 >= 0.1.28
• 编辑配置文件：vi config.toml

如果你的配置文件里还没有 [features] 这个字段，直接在文件末尾加上这两行就行：

[features]multi_agent=true remote_connections=true goals=true

重启 Codex

启动后直接输入：

/goal 修复当前项目中的bug

辅助插件

• github 代码协作、PR审查、项目维护
• Codex Security 扫描代码安全问题，辅助确认漏洞
• Figma 读取设计稿，辅助UI实现
• Linear 项目管理
• Sentry 排查线上问题
• Computer Use 操控电脑界面
• Resume-Matcher 简历优化定制精修

codex 多人协作开发 · 真实项目流程

1. 从git的主分支，创建一个功能分支，作为本次开发的独立环境，改动不会影响主线
2. 理解需求与方案，可用 规格驱动工具Spec-Kit、规范驱动工具OpenSpec
3. 开发与测试，可用 SuperPowers 测试驱动开发、Codex Security 扫描漏洞
4. 提交本地改动，提交要清晰、聚焦
5. 推送到 git 的功能分支
6. 发起 PR 审查，创建 Pull Request，描述改动内容、改动范围和diff，发起审查和合并流程
7. 安全合并

单工作树

接收到代码后，先做一次开发前的基线检查：

先做一次开发前的基线检查，不要修改业务代码。 请确认：1.当前 git 分支和远程仓库是否正确2.工作区是否干净，有没有未提交改动3.后端和前端依赖是否已安装4.后端、前端能否正常启动5.后端测试、前端测试是否通过 如果检查过程中发现是本地环境缺失导致的问题，比如缺少依赖、虚拟环境未安装完整，可以直接按照项目文档或者依赖文件补齐环境。 如果需要修改项目源码或配置文件，先说明原因，等我确认后再修改 最后给出一个精准结论：现在是否适合二次开发？

二次开发：

请帮我创建一个用于本次二次开发的功能分支。 本次开发目标是改造【】，使用分支叫【你取对应的名字】。 要求：1.先确认当前 git 工作区是干净的。2.基于当前主分支创建并切换到这个新分支。3.创建完成后告诉我当前分支名称4.不要修改业务代码5.不要提交 commit6.不要推送代码

需求分析，生成一份计划：

# 启动规划模式 需求如下...1.生成一份高质量的 proposal.md：把模糊需求拆成清晰的目标、明确的边界和可执行的验收规则 高质量的 proposal.md 不是把需求点逐条堆在一起，而是按照“目标 → 范围 → 验收”的顺序逐步收敛：先说明目标（为什么做），再说明范围（做什么、不做什么），最后说明如何判断完成-目标要交代任务背景、预期结果和判断标准。-范围为目标提供执行边界，也要写出必要的技术约束。-明确写出范围，可以避免 AI 自行扩大改动。-验收标准要把范围转换成可以观察和验证的结果，并覆盖关键边界。-验收标准要同时说明操作顺序、可观察结果和边界状态。-验收项还应该尽量量化。2.提交前检查这8项每次编写需求规范后，可以逐项检查：-目标明确：不了解项目背景的人，能否仅通过“目标”部分理解任务要解决的问题？-范围有界：是否同时写清楚要做什么和不做什么？-验收可测：每一条验收标准是否都能转化为可执行的测试或人工检查？-指标量化：涉及性能、尺寸或容量时，是否提供了明确数值和条件？-边界覆盖：是否说明了数据缺失、接口故障、空输入等异常场景？-不过度规定代码细节：是否避免把库选择、类结构和实现分支全部写死？-术语一致：同一个概念是否始终使用同一个名称？例如统一使用“LLM”，不要在全文交替使用“大模型”和“大语言模型”。-AI 可执行：把这份规范交给一个全新的 AI 会话后，AI 是否能理解任务做什么、不做什么，以及做到什么程度？3.使用AskUserQuestion（多轮追问）工具，像苏格拉底一样帮助我完善需求4.写成 最小修改+详细+全面+丰富+安全的计划方案（xx_plan.md）5.使用 蜂群多智能体模式，对方案和需求做审核、对抗、精细分析、对比、安全维度6.每个计划结束时，给我列出尚未解决的问题列表（如果有的话）7.开发完成后应该如何测试

按照计划执行，执行后验收测试

没问题创建本地版本，提交信息写清楚 精细到点，并告诉我版本编号

本地提交完成后，我们还不能马上推送功能分支。

这里先同步 main，是为了让 PR 尽量基于最新主线创建，减少后续才发现冲突的概率

推送前先获取远程 主线 的最新状态，并检查当前 功能分支 是否落后于远程主线。

如果远程main没有新的变化，功能分支可以直接进入推送前确认；如果远程main已经有新的提交，处理方式是把最新mainmerge 到当前 功能分支，再重新运行测试，再判断是否具备推送条件

请帮我同步远程 main，并准备推送当前功能分支。 要求：1.确认当前分支是 xxx功能分支。2.拉取远程 main 的最新代码。3.如果远程 main 有新提交，再将最新 main 合并到当前 xxx功能 分支。4.如果出现冲突，先说明冲突文件和原因，等我确认后再处理。5.如果执行了合并，合并完成后重新运行相关测试；如果没有新提交，也请运行相关测试确认可推送。6.测试通过后，告诉我当前分支是否可以推送。7.不要自动推送，除非我再次确认。

请将当前 xx功能 分支推送到我的 Gitlab 仓库。 要求：1.推送分支 xx。2.不要直接合并到 main。3.推送完成后告诉我远程分支地址。4.如果可以创建 PR，请先给我 PR 标题和 PR 描述草稿，等我确认后再创建。 可以参考下面的模版，你也可以自己补充：-关联的问题编号，如果没有就写 None-说明这次改了什么-选择改动类型-列出具体改动-说明怎么测试-如果有界面变化或关键代码片段，可以补截图或片段；没有可以留空、勾选已经完成的检查项、-补充信息；如果模板已有占位内容，按页面提示保留或补充-你的补充，关键核心维度5.不要自动合并 PR

多工作树

本地的 main 和远程的 main，并不同步更新。

先保证本地 main 和远程 main 保持一致。

后面所有新的功能分支，都应该基于这个最新的 main 创建，而不是基于旧版本继续开发。

请先帮我同步当前项目的 main 分支到远程最新状态，并做一次基础开发基线检查。 要求：1.先确认当前 Git 仓库状态。2.如果当前不在 main 分支，请先确认工作区是否干净，再切换到 main。3.拉取远程 main 的最新代码。4.确认本地 main 是否已经包含上一章合并进来的申请追踪页面改动。5.告诉我当前 main 分支的最新 commit hash。6.按照项目当前启动方式，启动后端和前端服务。7.检查后端健康接口是否正常。8.检查前端页面是否可以正常访问。9.尽量运行和申请追踪页面相关的测试；如果测试较多，可以优先运行最相关的测试。10.如果有前端 lint 或格式检查，也请运行一次。11.最后给我一个结论：当前最新 main 是否适合作为多分支协同开发的起点。12.不要创建新分支。13.不要修改业务代码。14.不要提交 commit。15.不要推送代码。

内化成选择题 skill：GitLab 安全提交向导

免费下载：https://download.csdn.net/download/qq_41739364/93732624

如果打开网页404，是因为刚刚上传，还在审核。

文档驱动开发 + 测试驱动开发，组合工作流 skill

AI 编程最大的问题就是不确定、验收需要大量人工工作。

那我们只需要在开发前用文档约束，在开发完成后用大量测试用例测试，就可以大幅度提升 AI 编程的可靠性。

复杂工程项目AI编程三件套工作流：

1. 规格驱动工具Spec-Kit应用
2. 规范驱动工具OpenSpec应用
3. SuperPowers 测试驱动开发 + 并发多Agent开发工程化应用

编程项目开发全流程定位：

• 意图和想法 -> 规范文档 -> 技术设计 -> 任务拆解 -> 编码实现 -> 质量

轻量文档驱动开发 openspec：规范文档 -> 技术设计 -> 任务拆解

全周期文档驱动开发 spec-kit：规范文档 -> 归档/交付全周期

测试驱动开发 superpowers：技术设计 -> 归档、交付

三者可以相互协作，最好是 spec-kit （更全面）+ superpowers。

这三个，你可以不用学习了，我打包成了一个技能：

• OpenSpec + Spec Kit + Superpowers 组合工作流

Superpowers 具备多智能体并行开发能力；但当前通用组合工作流默认是一个控制器下的安全串行实现，只有相互独立、环境隔离、文件不重叠的任务才允许真正并行。

组合工作流默认偏向安全串行。

当前组合协议是：

控制器维护唯一规格和任务图->同一计划中一次只有一个实现者写代码->每个任务完成后独立审查->最后统一集成、全量验证 它允许并行的事情主要是：-只读代码调查-多个独立故障的根因分析-已完成任务的评审-不同仓库、不同 Change、不同 Worktree 且文件范围不重叠的实现 不允许并行的事情是：-两个 Agent 改同一文件-两个 Agent 改同一 migration 链-同时更新同一份 tasks.md-同时操作同一数据库、锁文件、生成文件或共享环境-后者依赖前者接口、但接口尚未冻结