企业官网建设流程全解析

我见过不少号称“AI老板”的东西，但真正挂着系统跑满四个月、最后给出第一个“开除建议”的，这是头一个。这个项目我拆开看了一遍，本质是一个基于大语言模型的人事管理 Agent 系统：岗位需求丢进去，五分钟内自动生成招聘启事并发布到招聘渠道；员工入职后，它每周自动读日报、盯绩效、分析代码提交；到我写这篇复盘的时候，它已经对一位连续六周不达标的员工给出了解除建议，而且实际执行的是 HR，AI 只负责把证据链摆清楚。这套东西非常适合正在做 AI Agent 工作流、大模型部署，或者想用 AI 改造人事流程的团队参考，里面有不少值得抄作业的设计，也有不少必须避开的坑。

1. 项目整体设计与思路拆解

1.1 为什么想到让 AI 来当“老板”

先交代一下背景。这个项目不是公司正规立项，是几个工程师闲不住搞出来的内部实验。起因特别朴素：团队负责招聘的同事每天被 JD 撰写、渠道发布、简历初筛、面试安排这些流程化的事情绑住手脚，一天下来没时间做真正需要判断的面试和谈薪。当时内部已经在用大模型写文案、写代码，大家就问了一个问题：能不能让大模型把招聘到管理的整条链路串起来？

答案是可以，而且比想象中更顺。招聘启事本质上是“结构化信息 + 表达渲染”的组合，岗位需求是输入，JD 是输出，渠道发布是接口调用，每一环都是可以被工作流框架编排的。真正难的不是生成文字，而是怎么让整个链路在无人盯着的状态下稳定跑四个月，并且不出乱子。这个项目最值得说的也不是“AI 写了个招聘启事”，而是它证明了一件事：流程确定性足够高的管理场景，完全可以交给 Agent 工作流来做。

1.2 系统整体架构：四类 Agent 的分工

这个“AI 老板”不是一个单体大模型，而是由四类 Agent 组成的工作流网络。

• 需求解析 Agent：把产品经理或负责人口语化的岗位需求（比如“找个搞订单系统的后端，最好有高并发经验”）转成结构化字段，包括岗位名称、职责列表、硬性要求、软性要求、薪资范围、工作地点。
• JD 生成 Agent：基于结构化字段生成面向候选人的招聘启事文本，同时控制语气和长度。
• 合规审查 Agent：专门检查 JD 里的歧视性表述、年龄限制、性别倾向等敏感内容，发现就自动重写。
• 评估管理 Agent：负责简历初筛、面试追问、周报分析、绩效打分，以及触发预警。

前三个 Agent 只在招聘阶段工作，真正贯穿四个月的是评估管理 Agent。它每天定时任务，读取当天的代码提交记录、工作日志、任务完成状态，写入一个绩效指标库。预警模块各自独立，某个指标跌破设定阈值并不直接触发处罚，只有连续多周多维度不达标，才会进入人工复核队列。

1.3 为什么选择 Agent 工作流而不是单模型对话

最初有人提议干脆做个聊天机器人式的管理助手，管理者跟它对话，让它给建议。这个方案做演示没问题，但跑四个月会出大问题：对话型应用的输入不可控，今天问绩效、明天问午饭，状态管理非常混乱；而且没有固定流程，很多判断必须依赖上下文记忆，模型一旦忘了前两周的数据，整个评估就失真了。

所以走了 Agent 工作流方案。核心思路是：把流程固定在代码里，把判断留给模型。比如“每周五晚上八点汇总本周指标”是代码逻辑，而“这个候选人的回答是否体现自驱力”是模型判断。代码负责确定性部分，模型负责非确定性部分，两者边界清楚，排查问题也容易。实测下来，四个月里真正导致流程中断的故障绝大多数出在接口调用上，而不是模型判断漂移上——这正好印证了流程拆分的重要性。

2. 五分钟挂出招聘启事：核心实现过程

2.1 JD 生成的完整处理链

先看发布招聘启事这条链路。发起人只需要在系统里输入一句需求，比如：

“招一名资深后端工程师，Go 语言，负责订单系统重构，要求 5 年以上经验，有高并发项目经历，薪资可以给到 40K，办公地点北京。”

这句话进去后，需求解析 Agent 会把它转成结构化 JSON，大致是下面这个形状。配合结构化输出约束，模型不会漏字段，也不会自己额外发明一个“要求 211 学历”这种根本没人提过的条件：

from pydantic import BaseModel from typing import List, Optional class JobRequirement(BaseModel): title: str years_experience: int tech_stack: List[str] responsibilities: List[str] salary_range: Optional[str] location: Optional[str] extra_benefits: List[str] = [] prompt = """ 你是HR业务助理，请从下面的岗位需求描述中提取结构化信息： {raw_input} 要求： 1. 只提取原文中明确提到的字段，不要推测。 2. responsibilities 概括为主责描述，不超过3条。 3. 如果原文没有 salary_range，就返回 None。 """ raw_input = "招一名资深后端工程师，Go语言，负责订单系统重构，要求5年以上经验，有高并发项目经历，薪资可以给到40K，办公地点北京。"

输出 JSON 之后进入 JD 生成 Agent。这一步讲究的是“翻译能力”，要把内部语言转成候选人愿意看的话术。比如原文的“有高并发项目经历”会被扩写为“参与过日活百万级系统的接口优化与架构升级”。实测下来，GPT 级别的模型直接输出可用的 JD 成功率在九成以上，剩下的主要是语气过于生硬。

2.2 合规审查环节为什么不能省

JD 生成的另一头是合规审查 Agent。这一步是血的教训换来的。刚开始做的时候没有这个环节，有一次系统生成的 JD 里写出了“要求男性优先，因为需要频繁出差”，发布之后差点出大事。后来把合规审查 Agent 单独抽出来，专门检查年龄、性别、地域、婚姻状况、民族这几类高风险字段。

这个 Agent 的处理逻辑并不复杂：先把 JD 文本里所有实体和修饰词抽取出来，再做一次敏感类别判定。判定规则既有关键词匹配，也有语义判断。比如“年轻有活力”这种说法，关键词匹配不到，但语义判断会标记为年龄倾向，然后自动重写为“能够适应快节奏工作”。当时内部讨论过是否直接用提示词让模型“自我检查”，实测效果不稳定，还是单独一个 Agent 加规则兜底最可靠。

2.3 多渠道发布与实际可靠性设计

JD 审核通过后就到了发布环节。这个环节要对接招聘网站、公司官网、内部推荐群、社交频道等渠道。每个渠道的接口格式都不一样，有些是标准 REST API，有些只能通过机器人往群里发 Markdown。为了把这一步做成“五分钟挂出招聘启事”，工程上做了三个关键设计。

第一个是适配器模式。每个渠道一个独立适配器，底层接口怎么调用上层不关心。新增渠道只需要写一个适配器，不需要改动主流程。第二个是幂等控制。发布动作以岗位 ID 为幂等键，接口返回超时不能立刻重试，要先查询上一条发布请求是否已经成功。否则重试时很容易同一个岗位在网站上出现两次，后期删除反而麻烦。第三个是发布后校验。每个渠道发布成功后需要拉取一次页面信息，确认标题、薪资范围、工作地点渲染正常，防止接口返回成功但页面数据缺失。

时间构成方面，实测整个过程是这样分配的：需求解析加 JD 生成大约 45 秒，合规审查 5 秒，渠道发布 2 分钟，发布后校验加回调 2 分钟，预留 1 分钟重试。整个链路跑下来不到五分钟，其中最不可控的是外部渠道接口的响应速度，内部环节基本都在秒级。

2.4 几个渠道的对比实测

这条链路稳定跑了一个半月后，开始有候选人通过官网招聘页投递简历。简历进入系统的那一刻，才是这个“AI 老板”真正的工作开始。

3. 四个月运行中的关键机制：从简历筛选到绩效评估

3.1 简历初筛：规则与语义的双通道

简历初筛系统是四个月里迭代最多的模块。最开始只用一个 Embedding 模型算简历和 JD 的语义相似度，然后按相似度排序，排在前面的进入面试。跑了两个星期就发现问题：语义相似度会把“有着丰富项目管理经验”这种泛泛表述的简历排得很高，但真正做过复杂系统重构的简历反而因为术语表达差异被排到后面。

后来改成双通道。第一通道是硬性规则，比如工作年限、必会技术栈、学历门槛，直接过滤明显不达标的简历。第二通道才是语义模型，在通过硬性规则过滤的简历里做相关性排序。两个通道加权后得到综合分。实测首批 100 份简历，硬性规则过滤掉 71 份，语义排序后推荐了 12 份进入面试。这个 12% 的通过率跟人工初筛的习惯接近，后来就固定下来了。

这里要特别提一句：简历初筛的阈值必须让 HR 参与定。工程师容易陷入调模型的快感里，但模型指标不等于业务指标。简历召回率再高，候选人到面率低就是浪费面试官时间。四个月里我们把阈值从最初的 0.72 调整到 0.65，因为发现 0.72 会筛掉一部分学历一般但项目贴合的人，而 0.65 虽然多了一些噪音，但总到面率高不少。

3.2 AI 面试与评分卡：问什么、怎么追问

面试这个环节，AI 现在的水平还撑不住全流程。系统做的是“半自动面试”：AI 负责一轮结构化技术面试，面试官观察并负责终面。结构化面试的问题由模型基于 JD 生成，比如针对订单系统重构岗位，会生成“讲一个你做过的并发瓶颈排查案例”和“如果让你重写订单超时处理逻辑，你会怎么设计”这类问题。

追问逻辑是这里比较有意思的地方。面试 Agent 会根据候选人的回答提取关键实体，如果回答里提到了“Redis 分布式锁”，它会继续追问“锁的续期和红锁问题怎么处理”；如果候选人回答里没有出现具体技术名词，则追问会更偏向业务场景。评分用 5 分钟卡：技术深度、表达能力、项目匹配度、自驱力、风险点。一轮面试跑下来约 40 分钟，AI 会在结束后的 5 分钟内生成评分报告和录音转写摘要。

实测中一个比较准的观察：候选人如果在前 15 分钟内没有提到任何具体数据量级（比如 QPS、订单量、代码规模），后续表现大概率也一般。这不是面试官玄学，而是有数据支撑——四个月里面试评分前 20% 的候选人，93% 会在前 15 分钟提及量化指标。

3.3 试用期绩效：OKR、周报与代码数据的整合

员工入职之后，“AI 老板”就开始每个工作日收集数据。它的数据源是三个：项目管理系统里的任务状态、代码仓库的提交记录、周报文本。每周五晚上，三个数据源的数据汇入绩效计算模块，生成一个绩效简报。

任务维度的核心指标是任务完成率，代码维度的核心指标是提交频率、单次提交代码量、评审通过率，周报维度是靠模型判断员工本周是否有关键产出。四个维度的权重分配如下：

• 任务完成率：30%
• 代码质量与产出：30%
• 周报与关键产出：25%
• 协作响应度：15%

协作响应度是后来加的指标。当时发现有个员工任务完成率和代码指标都很正常，但同事普遍反馈他很难配合，群里 @ 他经常隔天才回。后来在绩效系统里接入协作响应时长，自动统计他回复同事消息的时间差中位数，直接把他的综合分拉下来了。这一步做完，绩效评估的准确度提高了不少，因为纯看任务数据很容易漏掉协作层面的问题。

3.4 模型部署与成本监控的实测数据

说下模型部署相关的经验。这个系统里的 JD 生成、简历筛选、面试评分分别在三个不同规格的模型上运行。JD 生成用了通用对话模型，走 API 调用，成本低、效果好。简历筛选的 Embedding 模型是本地部署的开源模型，用 vLLM 起服务，单卡 24G 就能跑，并发压力不大。面试评分模型最复杂，因为需要处理长对话转写，上下文窗口要求高，我们把它单独部署在一个 70B 级别模型上。

四个月里推理成本大约占整个项目开支的三成，另外六成是人力调试成本，剩下一成是渠道接口费用。如果是正式项目，我一定会建议先把模型调用做成内部网关，统一做缓存、鉴权和配额管理，否则每个 Agent 都直接调模型，接口密钥管理会乱套。这个判断在项目后期应验了：面试 Agent 和绩效 Agent 同时跑定时任务时，偶尔会出现并发限流错误，早期没有统一网关，排查起来非常痛苦。

4. 四个月后开除第一个人：触发、决策与复盘

4.1 触发条件：连续六周的低绩效信号

系统跑满三个月的时候，评估管理 Agent 的预警模块开始频繁提示一个编号为 E04 的员工。他的绩效数据非常典型：连续六周综合分低于团队基准分 25% 以上，任务完成率只有 31%，代码评审通过率从最初的 70% 一路掉到 44%，协作响应时长中位数超过 12 小时。最初两周预警被当成普通波动，但到第四周的时候，系统提示他维度命中数已达到 3/4，评估管理 Agent 自动生成了一个降级提示，要求主管介入。

这里需要说明：AI 不会直接“开除”任何人。系统生成的是绩效异常报告和解除用工建议，真正的解聘动作由 HR 和员工主管执行，最终盖 HR 章的是人而不是系统。但在流程层面，I 系统做了大量的证据固定：把每周绩效简报、代码提交记录、周报关键产出、协作响应数据完整打包，任何一条判断都能追溯。

4.2 决策链路：AI 建议，人决定

开除决策的工程实现可以总结成一条链路：指标预警 → 自动归因 → 复核建议 → 人工确认 → 书面通知 → 权限回收。前两步是系统自动完成的，后四步都需要人参与。

自动归因这部分系统做得比较有意思。它不是简单说“这个人绩效低所以建议开除”，而是会把低绩效拆到具体原因上。比如 E04 的周报里连续出现“依赖同事提供数据”“环境问题阻塞”这类表述，代码提交记录显示确实有一段时间集中在非核心模块上。系统给出的归因结论是“产出质量不足且长期未改善，而非环境阻塞导致”，这个结论是靠把周报文本和任务完成数据对齐后得出的。

人工确认环节我们坚持一个原则：任何解除决定都应该有至少一次面对面复核。AI 给的建议只能作为起点，主管和 HR 会和员工本人聊一次，了解是否存在系统无法感知的特殊情况。E04 这个案例里，复核后发现员工本人处于长期疲劳状态，确实不是态度问题，但考虑到产出长期不达标且已经连续两周没有任何关键产出，最终还是执行了解除建议。这个决定是团队集体做出的，AI 只是让证据更透明。

4.3 这次“开除”暴露的设计漏洞

这件事做完之后，团队做了一次非常认真的复盘。复盘发现一个此前完全没料到的问题：初筛简历时的量化指标偏好可能和实际岗位需求错位。系统筛简历时倾向于挑“项目经历多、技术栈广”的候选人，但这批人在真实工作里往往更擅长“广”而非“深”。E04 就是典型，他简历上有多个项目经历，面试表现也很好，但实际工作是长期深入重构一个模块，这种工作模式跟他的特性并不匹配。

另一个漏洞是试用期前两周的数据污染。新员工入职前两周本来就在熟悉环境，任务完成率低是正常的，但系统直接把这两周数据纳入绩效计算，导致 E04 的基线从一开始就被拉低了。后面我们把前两周设为“免考核期”，只采集数据不计入评分。

4.4 改进方案：多维度评估与人工兜底

针对上面的漏洞，系统在第四个月后做了三项升级。第一项是评估维度扩展，增加“长周期项目里程碑达成”指标，避免只看短期任务完成率。第二项是引入同事匿名互评，让团队成员的反馈也能进入绩效模型。第三项是设定三个月 baseline，任何新员工的绩效评分在入职后前三个月都只跟自己比，不跟团队基准比。

这套改进并不能让系统变成完美管理者，但至少让“开除”这个决定不再依赖单一数据源。我个人觉得，这里的核心不是技术，而是流程设计：AI 负责收集和分析数据，人负责做决策和承担后果。整套系统里最重要的代码不是模型调用，而是那条“必须经过人工复核才能执行解聘”的 if 判断。

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

5.1 五个高发问题速查表

跑四个月遇到过的问题远不止上面那些，我把最高频的几个整理成了一张速查表，方便后来的人排查。

5.2 关于人机边界、数据安全和流程透明的几条建议

最后说几条从这套系统里沉淀下来的实操经验，都是平时文档里不会写的。

招聘和绩效场景下，AI 的输出一定不能直接对外发送。JD 需要人确认一遍，拒信需要人看一眼，解聘建议更需要人点头。不是模型能力不够，而是出了问题需要有人负责。系统跑得再好，也不可能替你去开仲裁庭。我们在所有对外消息接口前加了一个“人审开关”，默认开启，只有内部测试时才临时关闭。

数据安全方面，系统里所有简历、面试录音、绩效数据都做了字段级脱敏。模型调用时传入的是脱敏后的文本，比如姓名用「候选人A」代替，手机号中间四位打码。面试录音转写之后原音频文件只保留 30 天，到期自动删除。这套做法在内部审计的时候很有用，至少能说清楚每一份数据被谁、在什么时间、用于什么目的。

流程透明方面，所有 Agent 的关键动作都记录审计日志。JD 生成了几次、谁确认的、发布到哪些渠道、简历筛选阈值是多少、面试评分卡谁填的，全部可回溯。E04 的解除决策之所以执行得顺利，很大程度上就是这些日志让整个流程经得起追问。

6. 写在最后：一些实际的体会

这套系统跑下来，我最深的体会是：AI 当管理者，价值不在“决策多聪明”，而在“过程多透明”。过去开除一个人，全靠主管的主观判断，员工不服气也没办法；现在 AI 能把六周的数据、代码记录、周报摘要、协作时长全部摆出来，争议一下子小了很多。这就是数据的力量，哪怕它只是一个辅助工具。

再分享一个小技巧。如果你也要做类似的人事 Agent 系统，开局千万别做“全流程自动化”。先做招聘启事这一个点，跑一周，确认模型输出稳定、渠道发布可靠、人工审核不烦，再往简历筛选、面试评分、绩效管理扩展。一次只拆一个流程，每个流程都加人工兜底，这是我踩过几次坑之后总结出来的最稳的路径。这套系统的下一步，我打算在解除建议里加入更丰富的上下文记忆，让 AI 的归因解释能结合员工长期成长曲线给出，而不是只看当前六周的快照。