把不确定性交给AI,把确定性交给代码
发布于 2026-06-13
315
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
文章主旨:在智能系统开发中,应平衡AI与代码的分工,将不确定性交由大语言模型处理,确定性交由传统代码处理,以实现可落地、可维护、高稳定的系统。
关键要点:
- 核心原则:不确定性(如输入形式、文本结构多变)由LLM负责理解与解析;确定性(如输出格式、数据校验规则)由传统代码负责固化执行。
- 案例一(智能功能点度量报告生成):LLM按固定JSON Schema提取非标文档数据,代码负责校验、计算并生成统一格式的Excel报告,确保输出稳定且规则更新只需改代码。
- 案例二(多格式人工报告智能对比):LLM解析任意格式人工报告,按统一Schema输出数据,代码进行对比并生成差异报告,通过强制原文引用和兜底校验降低幻觉风险。
- 案例三(动态可迭代的功能点度量规则适配):LLM动态学习最新度量规则文档,代码仅保留执行框架与校验逻辑,实现规则零代码迭代,避免面条代码与硬编码漏洞。
- 结语:分治设计思想通用适配文档处理、报告对比等场景,核心是“把理解模糊交给LLM,把精准执行交给代码”。
内容结构:
- 引言:指出软件系统开发中核心两难问题(输入多变 vs 代码僵化),提出真正可落地的思路是“把不确定性交给AI,把确定性交给代码”。
- 核心原则:
- 不确定性场景(输入形式、文本结构、语义意图动态多变)→ LLM处理。
- 确定性场景(输出格式规范、数据校验规则、业务逻辑固定)→ 传统代码处理。
- 职责:LLM负责“读懂模糊的信息”,代码负责“做对固定的事情”。
- 案例一:智能功能点度量报告生成
- 背景:针对格式不固定的需求文档输出固定格式Excel报告。
- 错误方式:纯代码解析(臃肿、难维护)或纯AI生成(不稳定)。
- 正确分工:需求文档→LLM按固定JSON Schema提取→脚本代码校验、计算、生成Excel。
- 落地效果:输出统一规范,规则更新只需改代码映射逻辑。
- 案例二:多格式人工报告智能对比
- 需求:用户上传人工报告,系统自动对比智能报告与人工报告差异。
- 升级分工:任意格式人工报告→LLM按统一Schema提取→代码校验→结构化对比→差异报告。
- 优化细节:强制LLM输出原文引用依据,代码兜底校验并标记待复核内容。
- 落地优势:一次开发全域适配,新增格式仅需微调LLM提示词。
- 案例三:动态可迭代的功能点度量规则适配
- 痛点:规则频繁迭代,传统硬编码导致迭代效率低、代码臃肿。
- 创新方案:LLM动态学习新规则文档,代码只保留执行框架和校验逻辑,彻底告别规则硬编码。
- 完整链路:最新规则文档→LLM学习→解析非标文档→代码校验→生成标准化报告。
- 核心优势:规则零代码迭代、摆脱面条代码、适配多场景、结果稳定可控。
- 结语:成熟智能系统应各司其职、优势互补,通用适配各类AI增强型系统,坚守“把理解模糊交给LLM,把精准执行交给代码”的原则。
文章总结:推荐采用“LLM处理不确定性、代码处理确定性”的分治设计,以实现智能系统的长期可迭代性与工程优雅。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 807.4K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
如何在软件质量管理活动中更好地使用检查单?
作者:任甲林 来源:希赛网 http://www.csai.cn 2006年6月28日 关键字:检查单 形式 内容 分类 发现效率 摘要:本文总结了在软件质量管理活动中,设计与使用检查单的6个基本要点,为更好地利用检查单从事质量管理活动提供了一个实用性指南。 检查单(Checklists)是软件质量管理活动中最常用的工具之一,通过检查单的作用是提醒检查人员检查哪些内容,避免遗漏。在设计
《非暴力沟通》读书笔记
1 “非暴力沟通”理念:不做价值判断,尊重对方和自己,让双方愉悦的达成一致,降低沟通成本、提高沟通效果。 非暴力沟通的适用场景:自我对话、与人交谈以及小组讨论。2 造成暴力沟通的因素:1) 道德评判。用自己的价值观评判别人的言行。如:你太自私了;你太冷漠了。2) 进行比较。比较也是评判的一种,两者相比,判定谁好谁坏。如:你看看别人是怎么做的,你是怎么做的。3) 回避...
为什么高成熟度的实施周期比较长?
很多软件公司在实施完成CMMI3级后,考虑实施CMMI4级或5级,在制定最初的改进计划时往往对实施高成熟度的难度估计不足,制定了很乐观的改进计划,改进的周期比较短。当领导基于乐观的估计拍板后,就很难真正地在实施高成熟度时见到实效了。如果要对实施CMMI高成熟度进行一个合理的工期估算,首先就要对CMMI的高成熟度是什么有一个清晰的、正确的理解。本文试图通过类比的方式,通俗地说明高成熟度是什么,高成熟
图解APH之engaging合弄
图一:Engaging合弄的目的与性能等级图二:Engaging合弄的活动 图三:Engaging合弄使用的敏捷仪式与技术
读的感触点
1 开发人员的快乐: 创建事物, 开发对他人有用的东西, 组装的魅力, 持续学习的快乐, 在易于驾御的介质上工作 开发人员的苦恼: 追求完美 由他人设定目标 对他人有依赖 查找修改BUG 过时的很快 2 BROOKS法则:向拖期的项目追加人手,只能让项目更拖期 3 设计人员要少而精 4 开发人员如何避免画蛇添足 5 非正式交流,正式交流,
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线