企业官网建设流程全解析

1. 先把"复用"这件事想清楚

我发现一个很有意思的现象：同样是天天用 AI 编程的人，效率能差出三到五倍。差在哪？不是谁更会写提示词，而是谁把提示词和配套的流程真正变成了能复用的工作流。今天这篇，我直接分享三个我自己已经在用、而且可以立刻搬到团队里用的 AI 编程工作流，每个都带具体的文件结构、配置思路和踩坑记录，你照着搭就行。

这里说的"工作流"不是某个按钮，也不是某一个单独的提示词，而是一条完整的链路：输入什么、经过哪些判断节点、产出什么、出问题怎么兜底。只有把这条链路固定下来，才谈得上复用。不然你今天写的提示词明天就忘，这个项目跑通的方案换到那个项目又要重新调，效率自然上不去。

这篇文章适合三类人：日常用 AI 写代码的个人开发者，想推动团队统一 AI 编程规范的组长或架构师，以及正在折腾 Coze、Dify 这类工作流平台、想把沉淀下来的方案固化成模板的人。三个工作流都由浅入深，前两个拿来就能用，第三个涉及一点平台搭建，我会把关键参数和设计思路都讲透。

先说清楚一个底层认知：工作流能不能复用，不取决于你用的工具多高级，而取决于你是否把"判断逻辑"和"具体内容"拆开了。凡是写死的部分都不可复用，凡是参数化的部分都能复用。这个原则贯穿今天三个方案的全部设计，建议你先记住这句话，后面每个案例都会反复用到它。

2. 工作流一：AI 编程提示词统一管理与批量复用

2.1 为什么提示词要"当代码管"而不是"当聊天记录存"

大部分人的提示词管理方式是这样的：写在聊天记录里，或者散落在十几个 Markdown 文件里，甚至就存在微信收藏里。结果就是提示词版本混乱，同一个任务有七八种写法，团队里每个人调出来的效果完全不一样。我自己最早也这样，直到连续几次因为提示词不一致导致输出质量翻车，才下定决心改造。

我的方案很简单：把提示词当成代码来管理。所有提示词进 Git 仓库，用统一的目录结构组织，用变量代替硬编码内容，配上版本历史和变更说明。这样带来的直接好处有三个：团队所有人都能拿到同一套标准；每次优化都能看到改了什么、为什么改；新项目接入时直接复制目录，五分钟完成初始化。

这套思路本质上和代码重构是同一件事。提示词也是资产，它需要命名空间、需要模块化、需要回归测试。你写代码的时候不会把函数全堆在 main 函数里，那提示词凭什么全堆在聊天框里？

2.2 具体目录结构与配置写法

我实际在用的目录结构长这样：

ai-workflows/ ├── roles/ # 角色类提示词 │ ├── senior_engineer.md # 资深工程师视角 │ ├── code_reviewer.md # 代码审查视角 │ └── traffic_guard.md # 安全审查视角 ├── tasks/ # 任务类提示词 │ ├── generate_api.md │ ├── refactor_function.md │ └── write_unit_test.md ├── templates/ # 带变量的通用模板 │ └── code_generation.md ├── context/ # 项目上下文 │ ├── project_tech_stack.md │ └── coding_standards.md └── rules/ ├── output_format.md └── constraints.md

每次在 IDE 里开始新任务时，我只做三步：

第一，根据任务类型选择tasks下的基础提示词；第二，用当前项目的context文件覆盖里面的变量；第三，如果需要额外约束，把rules里的规则追加进去。

模板文件长这样，核心是变量占位符：

# 任务描述 请根据以下需求生成代码： ## 功能需求 {{feature_description}} ## 技术栈 {{tech_stack}} ## 约束条件 - 必须遵循 {{coding_standard}} 编码规范 - 输出格式必须是 {{output_format}} - 不允许使用 {{blocked_libraries}} 中的依赖 ## 输出要求 代码块+关键逻辑说明，控制在合理篇幅。

这里面{{...}}就是变量。换项目时只改变量，不改逻辑结构。等积累多了，你甚至可以给每个角色配上一个"咒语开头"，比如senior_engineer.md开头固定是"请以资深后端工程师的视角，从架构合理性、边界条件、异常处理三个维度……"，这样输出的第一句话就定了调。

2.3 集成到 IDE 和团队协作

这套目录搭好后，我会把它设置为 IDE 的规则文件目录。以 Cursor 为例，直接把ai-workflows目录放到工程根目录，然后在.cursor/rules里引用；用 Continue 的话，在config.yaml里配置多个角色模板，按快捷键即可切换。核心思路是让 AI 客户端自己读到这些规则，而不是每次手动粘贴。

团队协作时，这套目录放在 git 仓库里天然支持代码评审。谁改了提示词，diff 里一清二楚；谁加了一个新任务模板，合并请求里就能看到。我见过更细的做法，就是在 CI 里加一个提示词烟雾测试，每次变更跑一遍标准输入，比较输出稳定性，避免某次改动让整体效果退化。

一个容易被忽略的点：不同 IDE 的规则文件路径和优先级不同，复制到新项目时容易漏。建议在仓库根目录放一个README.md，写清楚挂载步骤和常用命令，新成员加入时照着做就行。这一步听起来啰嗦，但能省掉后面大量沟通成本。

3. 工作流二：简历筛选自动化——一个能立刻跑起来的完整范例

3.1 把"筛简历"变成 AI 编程任务的思路

简历筛选是很多技术负责人最头疼的重复劳动。几十份甚至上百份简历，每份都要读、要对比、要判断，既费眼又费时间。而且人看简历有个毛病，看多了会疲劳，前后标准会漂移。AI 做这件事的优势在于标准稳定、速度极快，还能把每个评分理由写出来，方便你复核。

实现这个工作流的路径有两条。一条是用 Python 脚本直接调模型 API，适合有编程基础、希望完全掌控流程的人；另一条是在 Coze 这类平台上拖节点搭出来，适合不打算写代码、但想快速验证效果的人。两条路的核心逻辑完全一样，都是：解析简历文本、按维度打分、输出结构化报告、人工复核。

我建议第一次先用脚本跑通整个流程，因为脚本逻辑透明、方便调试；跑通了再拆到平台上。下面重点讲脚本实现方案。

3.2 分维度打分的提示词设计与输出结构

简历筛选不能只给一句"合适"或"不合适"，那样既无法解释也难追溯。我的做法是拆维度，每个维度单独打分，最后汇总。实际使用的维度如下表所示：

每个维度都要求 AI 输出 0-10 分的评分、一句结论、和关键证据摘录。最后的权重汇总由代码计算，不让模型做算术，因为模型的加权计算容易出错。这一步很关键：让 AI 只做判断，不做计算。

评分提示词的核心部分长这样：

你是资深技术面试官，请基于以下简历内容评分。 硬性技能匹配度：评估投递岗位JD与简历技能重叠程度。 输出格式（严格JSON）： { "tech_match": {"score": 0-10, "evidence": "...", "conclusion": "..."}, "project_relevance": {"score": 0-10, "evidence": "...", "conclusion": "..."}, "stability": {"score": 0-10, "evidence": "...", "conclusion": "..."} } 简历内容： {{resume_text}}

这里必须规定 JSON 输出格式，而且要写清楚每一个字段的含义。不约束格式，AI 输出的东西千奇百怪，后面解析就崩了。这也是整个工作流里我最强调的一点：结构化输出是所有可复用工作流的基石。

3.3 批量处理与人工复核机制

简历是一批一批来的，批量处理时我会把多份简历逐条送入脚本，脚本依次调用模型、收取 JSON 结果、计算加权总分、写入一个大的 CSV 文件。CSV 里每一行是一份简历，列是各维度得分和证据摘录，末尾加一列"推荐级别"（高/中/低）。

然后开启人工复核：我只看 CSV 里总分排名前 x% 的简历，以及风险信号分数极低的简历。AI 初筛把我的阅读范围从 100 份压缩到 15 份，效率提升非常明显。

这里有个必须强调的坑：AI 的评分永远不能替代最后的人工面试决定，尤其是候选人预期管理和决策责任这两个方面，AI 帮不了你。把它当成"阅读助理"而不是"决策者"，你会用得安心很多。

成本方面，一份 300-500 字的简历摘要，主流模型的调用成本几乎可以忽略；即便每天筛 100 份，费用也就在几块钱量级，比起你一个小时的阅读时间，这笔账怎么算都划算。实测下来，用低价的轻量模型就够完成初筛，只有特别边缘的案例才需要升级到高能力模型复评。

4. 工作流三：PR 代码审查与超大上下文应对

4.1 代码审查工作流的三大痛点

第三个工作流是 PR 代码审查，也是我日常用量最大的场景之一。它的难点和其他两个完全不同。对着一个几百行的 diff，人眼容易漏；让 AI 一次读完超长 diff，又容易超长上下文限制，或者后半部分注意力衰减、错误率上升。

我踩过几次坑后总结出的三大痛点：一是大型 diff 分分钟突破上下文窗口，报错或者输出质量急剧下降；二是审查负面问题严重——AI 对文件前部的意见详细，到后部就开始偷懒；三是审查结果格式不统一，有用的和没用的混在一起。

这三个痛点指向同一个解法：把大 diff 拆成小块，逐块审查，再把各块的结论汇总。核心思想类似并行计算里的分治策略：每个块都是独立的子问题，块与块之间不发生上下文污染，最后合并结果。

4.2 分块策略与超长上下文的应对方案

分块策略直接决定审查质量。我试过按文件分、按函数分、按行数阈值分，综合下来效果最好的是混合策略：

• 文件数量不超过 5 个且每个文件 diff 小于 200 行时，整份丢给模型一次审查；
• 文件数量较多时，按文件切分，每个文件独立审查；
• 单个文件 diff 超过 400 行时，再按函数或逻辑块切分；
• 切完的块仍超过窗口限制时，启用摘要压缩。

摘要压缩的具体做法：首先把超大 diff 块摘要成"变更文件列表 + 每文件的改动意图概述"，再把意图概述作为上下文、配合逐块 diff 进行细节审查。这相当于给模型提供了一个"目录"，让它带着全局认知逐页查细节，而不会因为细节过多丢掉主线。

如果你用的是 Coze 或 Dify 这类平台，上述逻辑可以用节点组实现，处理步骤类似：解析 diff、判断长度、分流到"直接审查"或"分块-汇总"分支、最后拼装输出。若使用 Dify，尤其要注意"上下文超长"报错往往不是模型能力不够，而是编排时把太多临时数据塞进了对话记录，合理的做法是在每个分支输出前主动裁剪历史消息。

4.3 接入 CI 与建立审查意见的闭环

审查工作流真正发挥威力，是接进 CI/CD 流程的时候。我建议的做法是：PR 创建时触发一个工作流任务，检出分支、拉取和主干的 diff、调用上面的分块审查脚本、把审查意见以评论形式发回 PR。这样每个 PR 都有 AI 的"第一轮意见"，作者在提交代码时就收到反馈，而不是等到人工 review 时才聊。

GitHub Actions 里触发代码如下所示：

name: ai-review on: pull_request: types: [opened, synchronize] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Run AI review run: | git diff origin/main...HEAD > diff.txt python review.py --diff diff.txt --output review.md env: LLM_API_KEY: ${{ secrets.LLM_API_KEY }} - name: Post comment uses: actions/github-script@v6 with: script: | // 读取 review.md 并创建 PR 评论

审查意见的输出格式我会固定用"严重级别 + 文件/行号 + 问题描述 + 修改建议"四段。这四段缺一不可：级别决定处理优先级，行号方便定位，描述避免空话，建议让作者直接能抄。每次审查跑完，我会把意见汇总统计到一个小面板里，看看哪些类型的问题出现频率最高，反过来推动团队改进代码规范。

这里有一个认知转变：AI 审查不是替代人工 reviewer，而是把人工精力从"找低级错误"挪到"讨论架构和设计"上。低级问题 AI 负责拦住，高级问题人工负责深聊，两者搭配才是健康节奏。

5. 常见问题与排查技巧实录

5.1 输出不稳定与上下文超长，优先查哪里

我自己一路搭下来，踩得最多的坑集中在四个地方，这里直接列成速查表给你：

其中"上下文超长"这个坑，平台型工作流里尤其容易踩。很多人在 Dify 里搭流程时，习惯把每个节点的输出都累积到对话变量里，造成翻倍扩张。我的经验是每个节点输出要立即结构化落盘，下一步只读取字段而非整个历史文本，这样上下文保持可控，成本也降下来了。

5.2 工具选型对比：脚本、Coze、Dify、n8n 怎么选

接触工作流平台一段时间后，不少人会纠结选哪个。我按自己的使用场景做个尽可能实在的对比：

我给团队的建议是：如果只是做一个内部小工具，先上脚本或 Coze 验证效果；如果明确要把 AI 流程和现有业务系统深度绑定，再考虑 Dify 或 n8n。而"复用"这件事，脚本用 Git 记录、平台用模板分享，都能做到，只是颗粒度不同。

5.3 几个让工作流真正"用起来"的补充技巧

最后分享几个让工作流真正可持续的小方法。

第一，把新发现的经验立刻固化成模板。每当我发现哪个提示词改一版效果明显变好，我会立刻更新仓库里对应的模板文件，并加一行变更说明。这个习惯坚持半年，你的模板库会变成一笔很大的资产。

第二，单位时间内只优化一个变量。不要同时改模板结构和模型参数，那样你根本不知道是哪个改动起的作用。一次只动一个，对比输出，再决定保留还是回滚。

第三，为工作流设计"失败逃生口"。比如简历筛选中，如果 AI 对某份简历输出的 JSON 解析失败，不要让它静默通过，而是放进一个"待人工处理"的列表。这类兜底逻辑不复杂，但有没有它决定了工作流在大批量场景下是稳定还是三天两头出问题。

第四，注意控制输入质量。简历内容如果是 PDF 扫描件，务必先做 OCR；代码 diff 如果夹带大量格式变更，先用工具过滤掉，这些前处理虽然不起眼，但能大幅提升下游效果。

写在最后

按我个人的体验，AI 编程工作流这件事，真正难的从来不是某个提示词写得多漂亮，而是把一套流程固定下来、让它能反复用、用在不同项目里还依然稳定。今天这三个工作流，从提示词管理到简历筛选再到 PR 审查，覆盖了不同复杂度的需求，但底层思路一致：先拆逻辑，再固化成模板，最后加上兜底。你不需要一次全上，挑一个最困扰你的场景先落地，跑通之后再复制到其他场景，效果会超出你预期。

如果你自己搭的过程中遇到了什么奇怪的问题，或者你有一套更好的分块策略，欢迎来交流。这些工作流离"完美"还很远，但每迭代一次，它就更皮实一点，也更像你的第二大脑。