——以方案生成、交叉评审与风险识别为例
一、从“不太相信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
