——以方案生成、交叉评审与风险识别为例一、从“不太相信AI”开始我是2023年初开始使用ChatGPT。那会儿写了篇灰色关联分析的实践记录[1]把和ChatGPT的沟通过程原样放进了文章里期待并热忱的拥抱新工具。但拥抱归拥抱信不信任是另一回事。最早让我起戒心的是写代码。它用pymgrid开源组件时[2]方法调得挺得体结构也像模像样可运行程序时就提示开源包里根本没有那个函数经核对其github官网[3]是凭空造出来的。对于通用性的内容AI大模型确实厉害聊概念、给框架、搭结构表现的很专业但一到具体组件的具体方法它敢给你编。后来才知道这叫“幻觉”——模型见过太多“长得像”的代码于是生成一个看起来合理、实际不存在的API。它编得越流畅你越容易上当。还有一点让我不舒服它不太会说“不会”。你问一个它拿不准的问题它总是给你一个解决方案——或者更气人的是把刚才那套方案换个说法再端上来。这跟模型的训练方式、上下文和不确定性处理都有关系不能简单归结为某一个原因。但实际体验就是回答流畅、语气肯定不等于正确。它可能把相似知识拼接成看似合理的结论也可能顺着你的假设继续推演而不主动指出前提里的问题提示“本回答由 AI 生成内容仅供参考请仔细甄别”。所以那段时间我的状态是用但每一条输出都留着后手。它给方案我先问一句“这个函数真的存在吗”它说完成了我逐行验证它推荐一个模型我先想“数据撑不撑得住”。后来试得多了我又发现另一层问题——很多次不是AI答得差是我问得含糊。目标没说清、角色没定准、前提和边界没划明就让AI既当业务专家又当程序员结果两头不靠。其实这不只是AI独有的问题——人与人协作角色含混、前提不清、各说各话也一样出问题。跟AI沟通不清楚某种程度上是人类协作老毛病的新投影。于是我换了个方式给公式、给数据、给约束分角色、分阶段多模型交叉评审。不是被AI说服的是试出来的。试到某一天它在我没想到的地方指出了一个边界漏洞我才觉得这东西可以进研发流程了。这篇文章就是一个从2023年就开始用AI、但始终不太相信它的老工程师把这套“试出来的工作流”整理出来供同行参考。核心一句话AI负责扩大候选方案空间工程师负责定义问题、识别约束、验证关键假设并对最终决策负责。二、AI提效的另一面课题负责人为什么更累我对AI的态度可以概括为三条原则审慎信任它给的是候选解不是结论人工负责方案、算法、边界、约束、最终决策责任在工程师可验证任何AI输出都要经过公式推导、数据校验、代码测试、小样本实验或同行评审。对AI的不信任不应表现为拒绝使用而应转化为验证机制。再说点实在的心态。我今年这个岁数快速写代码已经远远赶不上年轻人了。但AI把这个短板补上了一块。我现在的感觉就像带了一个能力比较强的研究生一起工作有理论、速度快还认真肯干活我出经验、定方向、判对错它出速度、出草稿、出候选方案。短短三年多我提报了10个发明专利8个已经发表。没有AI这个节奏肯定做不到。但研发的选题、边界、创新点、算法最终还是我一条条盯出来的。但这个“研究生”不是白带的。它效率高、出活快也逼着我提高两样东西统筹能力和快速学习能力。几十个变量、十几条技术路线、多个模型并行评审加上自己还要创新算法和方法调度不好就乱它抛来的新概念、新方法我不快速弄懂就没法判断对错。而且这个带得并不轻松比我自己干还累。快餐不好消化。AI给得快给得多可它给的公式、方法、术语我不认识、拿不准的还得回头研究。它抛来一大堆公式看着眼熟但不敢签字那就得查、得推、得找论文。它提速的那部分往往以我补课为代价。更累的是决策。小样本用什么算法、大数据用机器学习还是统计模型、数据怎么归一化——这些选型问题你让AI做它给你一堆方案可你得能说清楚为什么选这个、不选那个否则根本没法跟它有效交流它只会顺着你的含糊继续堆公式。说不清就交流不了交流不了结果就是一大堆你看不懂、判断不了的东西。还有一层风险得自己担。AI选型选错了、公式用偏了、方案过拟合了它不负责责任在工程师。这里有个结构性区别值得说清楚如果我只是个实现者规则都定好了、接口都明确了那AI提效明显我也不累。但研发方案阶段我是课题负责人方向、边界、选型、验收标准都得我定。这个累不是AI没用好是“负责人”这个位置本身决定的。放大能力的代价是真实存在的。说到这得把话说透一层要实现这种研发模式工程师得具备较高的系统能力、项目管理能力和领域判断力。没有这些能力打底AI用起来要么只能当学生——你教它什么它学什么要么只能当提效工具——写写代码、整理整理资料。真正让AI参与方案生成、交叉评审、风险识别的是工程师自己的判断力在托底。说到累还得说回AI怎么看我“具备研究生理论、高级工程师水平研究深度不够博士水平”。哈哈——这评价挺高的至少它拿博士标准来要求我了。是不是我的水平不够所以感觉很累呢我想过这个问题。后来想明白了累主要不是水平不够是位置决定的。 实现者按规则干活累在体力课题负责人定方向、担风险、做取舍累在判断。水平再高该担的判断一样不少水平不够连“累在哪”都看不清。AI夸你、贬你都不算数你能不能验证它、用好它才算数。三、研发工作流从候选方案到可验证结论3.1 先定角色再走流程走流程之前先定角色。我主力用DeepSeek、千问、ChatGPT的网页限流免费版。工具本身不稀奇稀奇的是怎么用。我的做法是把自己当课题负责人把AI当研发团队里的不同角色——业务专家解释场景和约束算法专家给模型和假设高级程序员给技术方案和伪代码交叉评审器/红队换视角挑错知识研究员补领域知识、替代部分初步检索。工具不固定对应角色DeepSeek可以先当生成器千问和ChatGPT轮换当评审器也可以让同一个模型换角色重来一遍。关键是换视角不是换窗口。免费限流版的应对是问题拆成小阶段每轮让AI先摘要上下文保存关键提示词和方案版本不传敏感数据重要结论人工复核。举个具体例子。写设计方案时几十个变量、参数符号人工复核和相互引用非常繁重。AI这方面确实强它能按你要求的统一符号定义来书写公式也能查出前后不一致的地方。但写完不等于对了还得人工复核。问题是复核本身有专业门槛。比如变压器损耗计算公式不是电力专业出身你根本复核不了比对确认也很费劲。有教科书能背书的还好办找不到教科书的就得去翻论文更麻烦。这个例子说明两件事AI能承担繁重的符号统一和交叉检查工作但最终复核依赖工程师的领域判断力判断力不够的地方就得启动知识越界处理——查教科书、找论文、换模型补课确认后再回馈。工具角色再清晰也替代不了专业底子。3.2 单模型迭代闭环最常用的工作流我提出目标、公式、数据、设想、边界、约束和评价标准初始模型给方案我判断是否基本符合预期其他模型评审挑漏洞我融入意见回馈初始模型多轮收敛人工决策并验证。概括为输入显式化 → 初始生成 → 交叉评审 → 人工融合 → 回馈优化 → 验证收敛。3.3 多模型独立生成再融合同一问题给另一个模型要求它独立给方案不查看第一个模型的输出。然后对比差异假设、算法、边界、约束、风险。融合优点形成候选方案再进入评审和验证闭环。但有一点必须说清楚多个模型给出相同答案不等于答案正确。不同模型可能共享相似的训练材料、公开知识和常见错误模式即使来自不同厂商也可能在相同的错误假设下形成一致结论。多模型交叉评审的主要价值是扩大错误的发现范围而不是通过模型投票来证明结论正确。真正的验证还得靠原始资料、计算、实验和测试。3.4 什么才算真正的“可验证收敛”多轮对话结束、AI不再提新意见、几个模型达成一致就算收敛了吗不算。我把它分三层第一层讨论收敛。候选方案趋于稳定主要技术路线和分歧已经明确不再无目的地增加方案。第二层技术收敛。关键假设得到核验——公式、数据、边界条件和关键实现已经通过适当的检查或测试重要风险有明确处理方式。第三层工程收敛。方案满足预先定义的验收标准——在目标场景、资源限制、维护成本和安全约束下达到可接受的要求剩余风险已被记录并接受。这三层不是每个项目都要严格走完的固定阶段而是一种判断框架。低风险的代码草稿讨论收敛加基础测试可能就够了变压器配置、工程安全或关键算法决策则需要更充分的技术与工程验证。最关键的是是否收敛更多靠人工确认按工程项目和课题要求来定而不是按“方法适合、大家赞同”来定。满足要求就不必再投入高昂的技术成本去追求“更优”。收敛的标准是工程目标不是技术极限。四、关键机制局部验证与知识越界处理4.1 快速验证局部方法与算法AI给的方案往往完整但未验证。不要等全案做完再验证验证过程是先对关键假设、公式、方法、算法步骤做低成本快速验证。但验证不是盲目试错有位博士同事跟我说过一句话研究者动手之前就该能大致预估结果的置信区间和成功概率。这话有道理但博士也常高估可行性工程师做可行性分析和风险预算本质是一回事。真正值得学的是那个习惯先预估再验证。 预估这个方案大概能成到什么程度、关键假设有多大概率成立、数据撑不撑得住、预期误差大概在什么范围、什么结果算通过。预估决定验证什么、验证到什么程度、什么时候停。AI最容易被跳过的恰恰是这一步——它给方案快但不替你估可行性这个预判还得工程师自己做。验证对象优先排序最可能推翻方案的假设、对结果影响最大的参数、数据条件是否支撑模型复杂度、边界和异常场景、与传统工程经验方法的基线差异。具体手段各有各的适用条件不能混着用边界值与反例构造检查逻辑在极端条件下是否失效基线对比判断复杂方案相对简单成熟方法是否有实际收益留出验证或交叉验证评估模型在未参与拟合的数据上的表现订单数据存在时间相关性时按时间切分比随机留出更合理AIC/BIC只在适用的统计模型框架内辅助比较拟合与复杂度样本很少、数据截断或观测相关时不能单凭它下结论敏感性分析识别哪些输入参数会显著改变输出结论复杂度估算判断运行成本、实现难度和维护负担。原则一句话先根据要验证的风险选择验证方法而不是固定使用一套工具清单。先验证“最可能推翻方案的假设”再验证细节先问“数据撑不撑得住”再问“模型精不精准”。4.2 知识越界处理机制当AI给出的方案超出我当前的领域知识范围我不让初始模型“自证正确”而是标记“知识越界点”用另一个AI工具做“知识补课”要求AI给出需要核验的原始资料、公式、实验清单我确认后再回馈初始模型仍不能确认的降级为“待验证假设”不进入最终方案。例如前面变压器损耗公式的例子有教科书背书的还好办找不到的就得翻论文确认后再回馈初始方案——这就是知识越界处理的现实场景。概括为识别越界 → 另一模型补课 → 原理与边界核验 → 回馈初始方案 → 人工确认或降级为假设。4.3 AI替代初步检索的边界AI可以减少初步探索的成本快速给术语、技术路线、常见方案和对比维度也能帮你扩展关键词、整理厂家资料线索、查找开源模型和组件的文档入口。但它不是信息终点。重要事实、公式、标准条款、设备参数、API版本、开源协议和论文结论都要回查原始来源。工程标准、制造商技术文件、原始研究论文和教科书的证据类型不同该查标准就查标准该查厂家资料就查厂家资料不能一概拿论文当最高依据。一句话AI帮你更快找到“该查什么”但不能替你证明“查到的就是对的”。五、案例复盘拟合更好为什么未必更合适例如最近分析订单数据为了快速落地我想要一个偏态分布、参数少的模型考虑伽马分布。初始模型给了方案另一个模型评审时推荐了beta分布或机器学习方法理由是拟合更灵活、精度更高。当时数据量不足业务环节环境也有约束。综合下来我选了beta分布拟合确实更精准——但代价是增加了分箱处理参数、流程比原来复杂了。今天回头看这次选型真正值得反思的不是beta分布一定比伽马分布差也不是拟合更好的模型就一定过拟合而是当时对模型适用条件、样本量和泛化能力的验证不够充分也偏离了“快速落地、参数少”的初衷。模型在现有样本上拟合得更好只能说明它对这批数据的描述更充分不能直接证明它对未来订单有更好的预测能力。样本量有限时参数估计的稳定性、留出数据上的表现、与简单基线方法相比的实际收益都需要考察。beta分布增加了分箱流程更复杂维护成本也上去了——这些工程代价当时没有充分权衡。总结经验第一拟合优度不等于工程有效性。局部指标好看不代表业务可承受、可维护、可落地。第二选型要围绕工程目标不是技术最优。我当时要的是“参数少、快速落地”AI推荐的是“拟合更精准”两个目标没对齐。第三AI评审要加“业务可承受性”维度。只让AI评“技术是否更优”不够还要让它评“数据撑不撑得住、业务容不容得下、工程养不养得起”。AI可以帮你找到“拟合更精准”的模型但只有工程师能判断这个“更精准”是否被数据量撑得住、被业务环境容得下、被工程成本养得起。快速验证局部方法就是防止“更精准”变成“更过度”的刹车。六、风险控制、AI代理与团队规范这套工作流的风险要讲清楚幻觉和错误公式、过时知识、领域约束理解不足、上下文漂移、隐私和数据安全、免费版限流导致上下文不完整、过度依赖导致判断退化、责任归属不清。对应措施是公式数据代码人工复核、敏感数据脱敏、多模型交叉验证、保存提示词和版本记录、关键方案双人评审、小样本实验先行、AI输出只作候选解。至于和AI代理的比较简单说本文讲的是对话式多模型迭代人做调度、评审、融合和决策AI代理是目标驱动、工具调用、自动规划执行适合边界清楚、可验证、低风险的多步任务比如资料检索、代码草稿、测试用例生成、文档整理。研发方案早期不确定性高、约束多、责任重更适合人机协同闭环不宜直接全自动。未来可以把低风险子任务代理化但要有权限、审计、验证和责任边界。不是反对代理而是先把“多模型迭代人工决策”跑通再把可验证的子任务交出去。个人用顺了可以往团队推建立提示词模板目标、输入、约束、输出格式、评审清单建立AI评审清单建立方案版本记录敏感数据脱敏规范重要结论人工签字负责把AI用于方案发散、评审、文档整理、测试用例生成而不是直接替代决策。核心一条AI输出进流程但决策和责任不进AI。七、结语AI放大能力也抬高门槛AI大模型在研发中的价值不在于一次给出正确答案而在于帮助工程师更快生成候选方案、更早暴露风险、更系统地讨论边界和约束。可信的不是模型本身而是“审慎信任交叉验证人工决策可验证收敛”的流程。这套流程放大工程师的能力也抬高工程师的门槛更要人承担放大的代价你要会统筹多角色协同要能快速消化它抛来的新概念要在变量符号统一之后仍能靠专业底子复核公式还要在选型、边界、风险上自己签字。快餐不好消化提效不是免费的——如果只是实现者规则定好了提效简单但作为课题负责人说不清就交流不了拿不准就得研究选错了就得自己担。没有系统能力、项目管理能力和领域判断力打底AI用起来只能当学生或者只能当提效工具。AI没有让我变年轻但它让我这个老工程师还能多往前看几步——前提是我始终知道哪一步该自己走哪一步该自己签字哪一份累是我该受的。参考[1]. 肖永威. 借助与ChatGPT对话进行灰色关联分析算法的应用分析. CSDN博客. 2023.02[2]. 肖永威. 用于人工智能研究的开源Python微电网模拟器pymgrid入门篇. CSDN博客. 2023.03[3]. ahalev. python-microgrid. GitHub. https://github.com/ahalev/python-microgrid