HR AI联合创新与可信交付服务

“

运行责任不会随着创建门槛的降低而消失。

故事中的观点分为两类：

• 有出处的理论与方法：在文中以括号标注来源，包括平台工程、领域驱动设计、安全软件开发框架和交易成本理论；

• 本文提出的方案性判断：如“七层架构”“应用升舱”“联合交付服务包”等，是基于与朋友聊天、大佬PPT以及与AI讨论推演出的设计框架，不是行业标准。

人物设定

知行数智的设定：人力资源领域服务商，愿景是成为人力资源领域的可信服务生态平台；除招聘、社保、背调、电子签等AI产品外，具备HR领域顾问、FDE工程交付团队、标准工程脚手架和可信交付工具链。

精选看点 · 非完整目录

一个标准的开场

十月中旬的一个周四，下午两点半，澄川集团总部十二楼的小会议室。

陈屿到得比约定时间早十分钟，把投影调好，第一页PPT写着一行大字：

AI时代，每个业务人员都是开发者。

周衡进门时扫了一眼标题，没说话，在靠窗的位置坐下。林岚晚了五分钟，进门先道歉，说招聘复盘会拖了。

陈屿讲得很流畅。

“过去两年，AI Coding是整个AI应用里渗透最快、落地最实的方向。以前一个内部小系统，从需求到上线，排期加开发加测试，三个月算快的。现在业务人员用自然语言描述，几个小时就能出一个可用的应用。”

“我们内部也是这样。销售自己做了商机看板，交付自己做了工时统计，HR自己做了面试安排。数字化的边际成本正在大幅下降，很多过去不值得立项的小需求，现在都值得做了。”

“所以我们认为，HR的AI转型，最好的切入点就是让业务自己动起来。我们有业务开发工作台、HR场景模板，还有招聘、社保、背调、电子签这一系列AI产品，可以——”

周衡抬了一下手。

“你说的这些，我们HR已经有人在做了。”

陈屿停下来。

“个人用得挺好。”周衡说，“问题是要给团队用、给公司用。我纠结的不是能不能做出来，是做出来以后怎么接进我现在的IT体系，还能长期改下去。”

会议室安静了两秒。

陈屿把PPT翻到了最后一页，然后关掉了投影。

“周总，那我换个讲法。刚才那一套，您大概听过不少次了。”

真正的问题浮出来

“我先说一个我们自己踩过的坑。”陈屿说。

“我们内部那个工时统计工具，做的人是交付部一个项目经理。界面很好看，比我们正式的项目管理系统好用。后来全公司推广，三周后出了问题——有人看到了不该看的部门成本。查下来，那个工具根本没有数据权限，只有一个登录页。”

“又过了一个月，他调岗了。工具出了个小毛病，没人敢动，因为没人知道他当时为什么那么写。”

林岚笑了一下：“这个我们也快遇到了。”

“一个人用的时候，很多事情是那个人自己在补：数据他知道哪条不准，规则他记在脑子里，出错了他自己改。一旦给团队用，这些隐形工作全部暴露出来——权限、数据一致性、版本、监控、交接，一个都绕不过去。”

“业务和IT现在都卡在中间这一段。业务觉得IT在设障碍，IT觉得业务在制造隐患。其实双方都没错，是中间缺了一套生产机制。”

周衡问：“什么机制。”

“让业务的创造能够升舱的机制。”陈屿说，“个人原型升成团队应用，团队应用升成企业生产应用。每升一级，补上这一级该有的能力，而不是要么直接上线，要么全部推倒重做。”

林岚讲了一个真实困扰

“我先讲个事情，你看看你们能不能解决。”林岚说。

“我们集团自己的开发团队，前段时间在做一个离职管理的模块。开发拿着我们给的制度文件和Excel模板，让AI出方案，然后直接开发。结果做出一个功能：让HR手工录入当地社平工资，说是可以避免离职补偿金被扣税。”

“看起来很贴心对吧？但这个功能的前提就不成立。补偿金的计税规则不是这么回事，而且让HR手填一个关键基数，本身就是风险。最麻烦的是，他们做完了才拿给我们看，之前一次都没来问。”

周衡补了一句：“开发说AI给的方案，看起来逻辑很完整。”

陈屿点点头。

“这就是现在AI开发最典型的问题。AI不缺逻辑，缺的是这家公司的业务事实。它读到制度文件、看到Excel字段，就会用通用知识把空白填满。填得越流畅，越像真的。”

“传统开发也会犯这种错，但传统开发慢，中间会有好几次被业务拦下来的机会。AI太快了，错误在被人发现之前，就已经变成了代码。”

林岚说：“所以你们怎么防？”

“靠两件事。一是让AI能读到的业务知识，必须是确认过的、有出处的；二是让AI生成的东西，必须先过业务样例的验证，才能往下走。”

“这两件事背后，其实是一整套架构。我画给两位看，不讲技术细节，只讲每一层解决什么问题。”

白板上的七个方框

陈屿走到白板前，从上往下画了七个横条。

“我先说清楚，这不是要卖您七套系统。贵司大部分底层能力已经有了，这张图是用来对照的：哪些已经有，哪些缺，哪些要连起来。”

他一层一层写上名字，然后把整理好的页面投到屏幕上。

周衡看了很久。

“第四层和第六层我们有。”

“对。”陈屿说，“这也是为什么我不建议您采购一个大平台。您缺的是第二、三、五、七层，还有把整张图串起来的人。”

“第一层，HR现在用的工具大多能用，统一登记就行。第四层和第六层是您的存量资产，我们接入，不替换。真正要新建的，是让业务知识可以被AI正确使用的第二层，让每个应用有统一起点的第三层，让发布有证据的第五层，和让应用长期有人管的第七层。”

为什么是这几层缺失

林岚问：“为什么偏偏缺的是这几层？”

“因为这几层在传统开发模式里，是靠人来补的。”陈屿说。

“以前开发人员脑子里有业务规则，那是第二层；有经验的工程师搭项目会自带规范，那是第三层；测试团队和上线评审在做第五层；运维和项目经理在做第七层。”

“现在业务自己开发，这些人不在场了。AI会写代码，但不会自动带上这些隐性的工程纪律。所以要把原来靠人的部分，变成平台能力和明确的规则。”

他指了指第三层。

“这一层，平台工程领域有个概念叫黄金路径（Golden Path）——企业预先铺好一条经过验证的标准路径，开发者走这条路，就自动获得身份、日志、测试、发布这些能力，不需要每次重新拼装。（来源：CNCF《Platforms White Paper》）”

“放在业务开发上，意思就是：HR说‘我要做一个入职跟踪’，AI不是从一个空文件夹开始写，而是从我们共同确定的模板开始。登录、权限、日志、部署方式全部预置好，AI只写业务部分。”

周衡问：“模板你们出，还是我们出？”

“我们出基础，您出约束。”陈屿说，“哪个身份系统、哪个代码仓库、哪种部署方式，这些是贵司的标准，我们按您的标准适配。”

“还有一点。我们参考过一个做零售数字化的架构实践，他们的原则是‘框架退后一步，让意图站到前面’——尽量少用隐式魔法，少做无意义分层，让人和AI一眼看懂这段代码在做什么。（来源：用户提供的《AI Coding的实践与思考》PPT）”

“这个思路我们认同，但企业里不能简单理解成‘越简单越好’。业务边界、权限边界、数据边界必须清晰，其他不必要的层次尽量去掉。模板的目标不是技术先进，是让下一个接手的人和下一次运行的AI，都不容易理解错。”

一个看似简单的问题

“回到第二层。”陈屿说，“林总，我问您一个问题。贵司怎么定义‘入职完成’？”

“人到岗了，手续办完了。”

“合同还没签完，但人已经开始工作了，算不算？”

林岚想了想：“那要看情况。”

“电脑没到，工位没好呢？”

“那不影响入职，但影响到岗体验。”

“劳务派遣和正式员工，标准一样吗？子公司和总部一样吗？”

林岚没马上回答。

“这就是第二层要做的事。”陈屿说，“这四个字在不同人、不同系统里含义不一样。一个人用的时候，她自己心里有数。给AI用、给团队用，就必须拆清楚。”

本体、SPEC与DDD的关系

周衡说：“你说的是企业本体？”

“对，我们管这一层叫企业本体与可执行SPEC。”陈屿说，“两者经常被混为一谈，但作用不一样。”

“方法上，我们借鉴领域驱动设计里的限界上下文。”陈屿说，“同一个词在不同业务范围里可以有不同含义，比如‘在职’，在薪酬里和在考勤里可能口径不同。关键是边界要明确，不能混用。（来源：Eric Evans《Domain-Driven Design》）”

“然后把需要跨应用共享、又需要机器能读的部分，沉淀为本体，规则必须带上出处：哪条制度、谁确认的、什么时候生效、适用哪些组织。”

“回到刚才社平工资那个例子，如果AI开发时能读到的，是一份确认过的离职补偿规则——基数从哪个系统取、计税口径由谁确认、HR哪些字段不能手工改——那个功能在设计阶段就会被挡住，而不是做完才发现。”

林岚问了一个很实际的问题：“我们不会为了这个，先花一年整理整个HR体系吧？”

“不会，那样项目还没开始就死了。”陈屿说，“做入职，就整理入职需要的部分；做试用期，再往外扩一圈。本体是跟着应用长出来的，不是建好了才开始开发。”

“但有一条要坚持：每做一个应用，沉淀下来的业务定义要放进同一个地方，而不是散在每个应用的代码里。第二个应用开始复用第一个应用的定义，价值才会出现。”

周衡问：“这东西归谁？”

“归贵司。”陈屿说得很快，“这是贵司的业务主权，不应该放在任何供应商的系统里不出来。我们帮着整理，但最终格式要开放，换供应商也能用。”

应用分级与升舱

“第五层我最关心。”周衡说，“但我先说清楚，我不想因为这个，把所有业务应用都变成审批流。”

“完全同意。”陈屿说，“如果可信交付等于每次修改都开会，HR三个月后就不用了，又回到私下用。”

“所以第一步是分级。风险不同的应用，走不同的路。”

“大部分HR应用会停在L1和L2。L1基本自动，L2多一次业务确认。只有极少数到L3，才需要您的架构和安全团队真正介入。”

“这样您的人只处理少数高风险的例外，而不是被所有小需求淹没。”

门禁里检查什么

“自动门禁具体查什么？”周衡问。

陈屿掰着手指说：

“技术侧，有没有明文密钥、有没有越权读取、依赖有没有已知漏洞、有没有日志和回滚方案。这部分我们参考美国国家标准与技术研究院的安全软件开发框架，核心思想是安全要贯穿开发全过程，而不是上线前临时补一次扫描。（来源：NIST SP 800-218《Secure Software Development Framework》）”

“业务侧，HR提供的正常样例、异常样例、历史上出过问题的案例，会变成自动回归测试。规则改了，旧场景要先跑一遍，确认没被破坏。”

“还有一项很多人忽略：真实界面测试。不是看接口返回对不对，而是用浏览器真实走一遍——HR进来能不能找到待办，点进去是不是对应员工，办完以后状态有没有变。

林岚说：“这个要有。以前验收是开发在演示，我们的人一上手就找不到按钮。”

“所以我们的验收不是开发演示，是找没参与设计的HR同事，拿真实任务做。卡住了就记录，旁边的人不许教。”

周衡问了一个尖锐的问题：“AI写代码，又写测试，一起错怎么办？”

“这个风险真实存在。”陈屿没有回避，“所以业务样例和权限边界，必须是独立于本次生成过程的约束，由HR和IT确认，AI不能自己改。测试通过不等于业务正确，只说明它没有违反我们已知的规则。”

“我们对可信交付的定义是：不承诺永远不出错，而是上线前有证据，上线后能发现，出了问题能止损，版本能回退，责任能找到人。”

“每次发布，会自动生成一份记录：哪个版本、用了哪版规则、测了什么、谁确认的、回滚到哪里。我们叫它交付护照。审计来了直接拿出来，不用临时补材料。”

周衡问出了最关键的问题

周衡往后靠了靠。

“架构我认。但说实话，这些东西我为什么不自己做？招两个人，再加点工具预算，不也一样？”

这是陈屿等了整个下午的问题。

“周总，如果贵司每个月都有稳定、足量的业务应用需求，而且已经有平台团队和测试团队，自己招人完全合理。我不应该劝您把所有能力外包。”

他停了一下。

“但我们一起算一下，要把刚才这条链路跑起来，实际需要哪些能力。”

他在白板上写下一列：

• 懂HR流程、能把隐性规则问出来的业务分析；

• 能接身份系统、HR系统、审批流的集成工程；

• 能驾驭AI开发、又守得住工程纪律的开发者；

• 能设计业务回归和安全检查的测试能力；

• 能把应用接入运行平台的运维能力；

• 跟得上模型和工具快速变化的技术判断。

“两个人覆盖这六项，可以做到，但很难做好。更麻烦的是需求不均匀——有时候HR一个月提五个需求，有时候一个都没有。忙的时候人不够，闲的时候能力闲置。人走了，还要重新招、重新培养。”

“经济学里有个说法，企业决定自己做还是对外采购，比较的不只是生产成本，还有交易成本——寻找、协调、监督、更换的成本。（来源：Oliver Williamson《The Economic Institutions of Capitalism》）对甲方来说，内部保有一支全能力团队的成本，不只是工资，还包括招聘、培训、替补、闲置和管理。”

“我们作为乙方，同样的能力服务多个客户，脚手架、测试工具、接入组件、HR领域模板可以复用，专家可以在多个项目之间调配。这是规模复用带来的成本结构差异，不是我们比贵司的人更聪明。”

乙方主动说出自己的边界

林岚问：“那有什么情况，我们自己做更好？”

陈屿的回答让周衡有些意外。

“有几种情况。第一，贵司AI应用需求长期稳定且量大，足够养一支专职团队；第二，业务高度专有，外部团队学习成本过高；第三，数据和系统限制极严，外部人员很难接入；第四，跟我们协调的成本，已经高于内部自己做。”

“出现这些情况，您就应该扩大内部团队，把我们的角色缩小到工具和专家支持。我说这些，是因为如果我们没有可复用的资产，只是派几个工程师过来写代码，那就是普通人力外包，对您没有额外价值。”

周衡点了点头，这是他今天第一次主动点头。

“那你们觉得，什么该我们自己做，什么该你们做？”

自研、采购与共建的分工

陈屿把七层架构重新分成了几块颜色，投到屏幕上。

“上面的企业语义是贵司的差异化，必须握在自己手里；下面的通用工程是可复用的专业能力，适合采购；中间的接入和应用，我们一起做。”

不是驻场开发，也不是售前

“你前面提了几次FDE。”林岚说，“我们HR的人可能没听过。”

“FDE，Forward Deployed Engineer，前线部署工程师。”陈屿说，“这个角色最早在一些做复杂企业数据平台的公司里比较典型。说白了，是坐在业务和IT中间，负责把事情真正做成的人。”

“他跟传统驻场开发不一样。驻场开发等需求文档，做完交付；FDE是跟HR坐在一起看实际工作怎么做，把隐性规则问出来，判断哪些调现有系统、哪些要开发，然后带着AI工具实现，再跟IT一起接入和发布。”

“他也不是售前。售前讲完就走，FDE要对上线以后能不能用负责。”

周衡问：“一个人能懂HR，又懂集成，又懂AI开发？”

“很难，所以我们不卖单个人头。”陈屿说，“前面一个稳定的FDE，熟悉贵司的业务和环境；后面有我们的HR产品顾问、架构师和测试支持，按需调用。您采购的是一个有交付责任的服务单元，不是派一个人来等任务。”

用入职跟踪工具走一遍

林岚说：“那拿我们那个入职工具举例，FDE进来具体干什么？”

陈屿把流程写在白板上：

1第一周，跟用户坐在一起

• 让做工具的同事现场操作一遍；

• 记录哪些状态是她手工维护的，哪些可以从系统取；

• 把“入职完成”这类词拆成明确的规则，请林总指定的负责人确认。

2第二到三周，决定保留什么

• 评估现有原型：能直接改造、需要局部重做，还是不值得继续；

• 写出评估依据，而不是一句“原代码不规范”。

3第四到六周，接入与升舱

• 换到标准脚手架上，接公司登录和组织权限；

• 员工主数据只读，从现有HR系统取，不另建员工库；

• 合同状态从电子签平台取，IT任务关联现有服务台；

• 补齐业务回归测试和真实界面测试。

4第七到八周，灰度上线

• 先给共享服务中心一个小组用；

• 监控使用情况和误报情况；

• 没参与设计的HR同事做验收。

5之后，完成一次真实迭代

• 比如增加一家子公司的流程差异；

• 由FDE以外的工程师，依据仓库里的本体、SPEC和测试完成修改；

• 验证这套东西是否离开原作者也能持续改。

“为什么非要做一次迭代？”林岚问。

“因为第一次上线只能证明我们做出来了。”陈屿说，“软件最大的敌人是迭代——屎山代码、新bug、文档混乱，大部分问题都出在改的过程中。改过一轮还能稳定，才说明这条路能长期走。”

周衡没说出口的顾虑

讨论到这里，周衡沉默了一会儿。

陈屿看出了什么。

“周总，我说一句可能不太该说的话。很多企业里，业务找外部团队开发应用，最后会被内部IT卡住。不是IT故意为难，而是外部团队做完拍拍屁股走了，出了事还是IT兜底。换我是IT，我也会卡。”

周衡看了他一眼：“你倒挺清楚。”

“所以我们的方案里，IT不是被绕过的一方，而是这条生产线的所有者。”

“黄金路径是IT定标准，门禁规则是IT批准，生产授权是IT掌握。FDE是在IT铺的路上干活，不是另开一条路。项目成果对外汇报，应该是IT牵头建立了业务自主创新的生产机制，HR是第一个受益部门。”

“而且我们会刻意培养贵司内部的人。IT出一位对接人全程参与，HR出一位业务负责人。首期结束时，他们要能独立判断：一个新需求属于哪个等级、走哪条路径、哪些可以HR自己做。”

周衡说：“你们不怕教会了我们，就不用你们了？”

不按代码行数，也不按人头

“说商务吧。”周衡说，“你建议怎么签？”

“分三段，每段都有明确成果，每段结束都可以重新决定要不要继续。”

“周期是基于常见情况的建议，评估以后可能调整，我现在不承诺三个月一定能完成所有内容。”

周衡问：“为什么不直接报联合交付的价？”

“因为不看代码和接口就报总价，要么报高了您不签，要么报低了我们做不完，最后两边都难受。”陈屿说，“现在市场上低价中标、然后靠变更补回来的项目太多了，甲方乙方都很累。我宁可先花两三周把底摸清楚，再给一个能兑现的数字。”

林岚和周衡各提了一个条件

林岚说：“效果怎么衡量？我不想最后只验收‘系统上线了’。”

“上线前先记录基线。”陈屿说，“现在入职准备每周HR花多少时间催办，漏项有多少，新员工到岗第一天缺东西的比例。上线后看这些有没有改善，也看真实使用率。”

“具体指标双方共同定，我不先承诺一个百分比。先确认基线，再对共同认可的结果负责。如果没人用，就找原因改，不用‘发布成功’掩盖业务失败。”

周衡说：“我的条件是退出。合作结束了，我能接得住。”

“这个写进合同。”陈屿说，“源码、部署配置、本体、SPEC、测试用例、交付护照，全部在贵司仓库，格式开放。如果用到我们的专有组件，提前列清单，说明替代方案和迁移成本。不会等到要退出的时候，才发现有东西拿不走。”

“报价也拆开：首次接入、FDE服务、平台许可、运行与模型费用、持续服务。哪些是一次性的，哪些随应用数量增长，哪些贵司已有不重复采购，全部写明。”

周衡点头：“别第一期便宜，后面每次改都天价。”

“常见变更类型和计费方式提前约定。标准配置、一般功能调整、跨系统改造分开定价，不混在一起。”

会议的最后十五分钟

林岚翻开笔记本。

“HR这边我来牵头。入职工具作为候选，但我让团队再拿两个场景出来，评估的时候一起比较，别为了保留原型硬选。做工具的那个同事，还有两个以后真要用的人，都要参加工作坊。”

周衡说：“IT这边我出一个负责人，把现有身份、HR系统接口、代码仓库、发布平台的情况整理好给你们。标准范围内的接入，我们内部给明确处理时限，不让试点一直等审批。”

“我们这边，”陈屿说，“启动评估阶段，我带HR产品顾问、架构师和预定的FDE一起来，不只有销售。”

周衡想了想，又补了一句。

“建议书别写成‘采购AI开发平台’。写成HR AI联合创新与可信交付服务。先签启动评估，结果满意，直接转联合交付。”

“好。我们下周三之前把建议书给到您，包括服务范围、人员投入、阶段成果、双方责任、退出条款和报价结构。”

林岚合上笔记本，说了一句：

“其实我不在意HR写了多少代码。我在意的是，以后一个同事想到好办法，不用等三个月；她休假了，事情也照常跑。”

陈屿说：“这也是我们首期要交付的东西。不是让每个HR都变成程序员，而是让好办法不再只能留在某一个人手里。”

会后

陈屿走后，周衡在日历里把这次会议的标题，从“知行数智产品交流”改成了：

“HR业务自建应用升舱：启动评估立项”。

他给采购部发了一条消息，让对方准备一份专业服务类的采购流程，预计两周内提交。

陈屿在电梯里，把白板照片发到公司群里，只写了一句：

“澄川这单，卖的不是AI，是中间那一段。”

本文的核心论点

AI降低了应用的创建门槛，但没有同步消除企业的运行责任。企业真正需要建设或采购的，是把个人创造转化为组织能力的生产机制。

四个支撑框架

能让这单谈成的三个关键动作

1乙方主动说出自己的边界

承认甲方在某些条件下自建更合适，反而建立了信任。

2把IT放在生产线所有者的位置

化解“外部团队绕过IT”的组织阻力，让CIO成为合作的受益者。

3用分阶段、可退出的服务包降低决策门槛

首期只签启动评估，成果明确、风险可控，让甲方能够立即做出采购决定。

甲方控制业务规则、关键资产和生产决策，乙方提供可复用、可弹性采购的专业能力，双方在现有IT基础上共同对业务结果负责——这是故事想传达的合作模式。