这两年我一直在琢磨一件事AI 到底能把软件研发的上限抬高多少。前几年大家聊 AI 辅助开发基本都集中在“帮你补全函数”“帮你写正则”这种单点小技能上。但真把一个完整项目从需求拆解一路推到上线运维AI 能介入的环节远比想象中多。我把自己和几个技术团队在“AI 驱动的 SDLC 技能提升”这个方向上踩过的路、趟过的坑、沉淀下来的方法完整梳理一遍这篇东西不是科普 AI 有多强而是记录一套可复制的实操路径在软件开发生命周期SDLC的每个阶段AI 分别能干什么、怎么干、以及哪些地方压根不该用它。这套内容适合谁如果你是后端或前端开发想在写代码之外把需求分析、测试设计、架构评审这些软技能也补上来如果你是技术 Leader正琢磨怎么让团队整体产能再上一个台阶甚至你是刚入行的新人想知道 AI 时代该往哪个方向沉淀自己的不可替代性——这篇都有可以直接拿去用的方案。1. 整体设计思路不是“用 AI 写代码”而是“用 AI 重构 SDLC 技能栈”一开始我和多数人一样以为 AI 驱动的 SDLC 技能提升核心就是让 AI 写业务代码开发者变成审代码的。实践了三个完整项目之后我的结论完全反转AI 对 SDLC 的改造不是简单替换“编码”这一个环节而是重新分配了整个生命周期里人的精力结构。传统 SDLC 里开发者 60% 以上的精力消耗在信息查找、代码拼写、重复性调试上真正用于思考业务逻辑、系统边界、风险控制的时间不到三成。AI 介入后那些低价值环节的耗时被大幅压缩人会自然地把精力往上游挪需求讨论、架构权衡、测试策略、线上稳定性设计——这些恰恰是高级工程师的核心技能。这个认知转变是整个方案的基石。如果你的目标还停留在“让 AI 帮我写得快一点”那只是工具层面提效但如果把目标定义为“用 AI 驱动整个团队在 SDLC 每个环节的能力成长”你会发现完全不同的落地路径。1.1 分层设计AI 在六个生命周期阶段的技能映射我习惯把 SDLC 拆成六个阶段需求分析、架构设计、编码实现、测试验证、部署发布、运维监控。AI 在每一层都承担不同角色对应的技能提升点也完全不同。SDLC 阶段AI 承担的角色人的技能提升方向需求分析需求澄清助手、用户故事拆解器结构化表达、边界梳理、验收标准设计架构设计方案评审顾问、风险识别器架构权衡、技术选型判断、文档化能力编码实现结对编程伙伴、代码审查员代码规范、设计模式、安全编码意识测试验证测试用例生成器、缺陷分析器测试思维、边界条件设计、根因分析部署发布发布检视员、回滚决策辅助发布策略、环境管理、自动化意识运维监控日志洞察员、告警降噪器系统运维认知、故障排查、性能调优这个表格看着简单但它解决了一个关键问题AI 不是只属于“写代码的人”的工具而是贯穿全生命周期的能力放大器。比如测试阶段过去很多人觉得写测试用例是苦活AI 能瞬间生成几十个用例这时候人的核心价值就不是“写用例”而是判断哪些用例值得保留、哪些场景需要组合覆盖——这恰恰是测试设计能力的真正来源。1.2 为什么选择“技能提升”作为切入点而不是“流程自动化”很多团队一上来就想搞全流程自动化用 AI 把需求到发布的链路全部串起来。我见过好几个这样的项目最后都卡在同一个地方AI 的幻觉、上下文漂移、以及异常分支处理导致自动化管线在 80% 的常规场景跑得很顺一旦碰到 20% 的边界场景就全线崩溃而调试这条 AI 管线的成本远超人工直接处理。所以我坚持把切入点放在“技能提升”上每个阶段用 AI 辅助人来完成工作而不是取代人。区别在哪辅助模式下人始终掌握最终决策权AI 的输出是参考、是初稿、是反向验证的镜子自动化模式下人的角色退化成监视器技能不仅没有提升反而会因为长期不实操而退化。从团队能力建设的角度看辅助模式是可持续的自动化模式会形成技术债和人才债的双重积压。我给自己定了一条实操准则也建议所有想复制这套方法的人遵守AI 输出的内容必须经过人的改写才能进入正式交付物。哪怕是 AI 生成的测试用例你也得逐条看一遍理解它为什么这么设计边界值然后按自己的理解调整。这个“改写”动作就是技能内化的过程。2. 核心细节解析每个阶段 AI 辅助开发的具体打法2.1 需求分析AI 帮你把模糊想法逼成可验收的文档需求阶段是 SDLC 里最容易被 AI 化也最容易被搞砸的地方。我见过团队直接用 AI 把一句“开发一个用户登录功能”扩写成三百字的需求文档看着很唬人其实没有任何可执行性。正确用法是把 AI 当“澄清工具”而不是“代笔工具”。我自己的操作套路分三步。第一步先让业务方用一两句话描述核心诉求不去做任何结构化第二步把这段原话扔给 AI让它列出至少十个澄清问题比如“登录方式支持哪些第三方登录是否需要忘记密码的流程走邮箱还是短信账号锁定策略是什么”——这些问题不是 AI 发明的而是它的训练数据里涵盖了海量真实需求文档的常见边界正好帮我补上经验盲区第三步我拿着这些问题去和业务方逐条确认把答案喂回给 AI让它生成带验收标准的用户故事。这里有个非常关键的细节验收标准的生成要让 AI 给出“可测试的、量化”的描述而不是“系统应保证用户能正常登录”这种空话。你可以直接在提示词里加约束比如“每条验收标准必须以『当…时系统应…预期结果是…』的格式输出且必须包括异常路径”。需求阶段 AI 辅助带来的技能提升不是写作能力而是提问能力和边界感知能力。和业务方过澄清问题的时候我会刻意先不看 AI 的问题清单自己列一遍再对照 AI 列的看差异在哪里——差异处就是我的经验盲区多看几次自己的需求分析能力会明显变强。2.2 架构设计AI 做“反向评审”专挑你自己看不见的漏洞架构设计是 SDLC 中 AI 最难替代、但辅助价值最高的阶段。难点在于架构决策依赖大量隐性经验业务未来三五年可能的走向、团队的技术熟程度、运维成本承受能力这些 AI 都不了解。但 AI 有一个天然优势它能快速识别架构描述中的“风险点惯性缺失”。我常用的模式叫“反向评审”。先把自己设计的架构方案完整地写成文档包括模块划分、数据流向、接口协议、部署拓扑然后让 AI 扮演六个不同角色依次挑战这个方案资深 DBA挑数据存储和查询设计的毛病、SRE挑高可用和容灾设计的问题、安全工程师挑权限和敏感数据处理的隐患、前端架构师挑 API 设计对端侧是否友好、产品经理挑扩展性是否覆盖未来三个迭代、新手开发挑文档中没写清楚会导致误操作的地方。每个角色都给独立的上下文窗口避免前面角色的结论污染后面的判断。六份评审意见汇总后我再统一处理能改的改不能改的标记出来注明理由真正有价值的架构风险往往就藏在那些多角色交叉指出的区域。这个过程对比传统架构评审会议最大的差异是“批评密度”。人工评审时大家碍于情面或者因为没深入细节提不出太多尖锐问题AI 评审每轮都能给出十条以上的问题点其中混着一部分废话但提炼出的三四条有效建议往往就是真正会埋雷的地方。长期训练下来我自己画架构图时也会下意识先检查那些 AI 反复提问的环节——这种“预判风险”的敏感度就是架构师的核心技能。2.3 编码实现人机协作的节奏感比生成代码量更重要到了编码阶段很多人的第一反应是“让 AI 写全部代码”。我强烈建议放弃这个念头。在我的实践里AI 辅助编码的最佳比例是结构性代码 AI 写逻辑核心人写边界代码两者合写。结构性代码指那些模式固定但不允许出错的模板——配置类、序列化类、接口定义、ORM 映射这些代码的价值密度低但出错成本高AI 生成后人工 review 的成本远低于手写。逻辑核心代码指业务规则、算法选择、状态流转这类决定系统行为的代码这部分必须自己写因为只有亲自动手才能保持对系统演进的掌控感。边界代码指输入校验、异常处理、重试补偿这类代码建议先自己写一版再用 AI 生成的结果对照看是否有遗漏的异常场景。我还有一个独家习惯每完成一个模块的编码就强制自己用自然语言向 AI 描述一遍模块的核心流程、关键决策和潜在风险点然后让 AI 根据这段描述画出模块的状态流转或者时序逻辑我再对照实际代码检查偏差。这个习惯的额外收益是每次“描述—生成—对照”的过程都在训练我把代码逻辑转化为结构化表达的能力这对后续输出技术文档和带领新人都有直接帮助。编码阶段最重要的技能不是“写代码”而是“判断什么该让人写、什么该让 AI 写”。我从实践中总结了一个判断标准如果这段代码的逻辑正确性完全取决于你的业务理解那就自己写如果取决于通用规范和已知模式那就让 AI 写然后 review 规范性即可。照这个标准执行AI 生成的代码 review 速度能提升一半以上同时系统质量不会因为依赖 AI 而下滑。2.4 测试验证AI 生成用例的数量不重要覆盖逻辑才是关键测试阶段是我个人认为 AI 提效最明显、但团队最容易迷失的环节。很多人让 AI 一键生成几百条测试用例看数量很满足实际执行完发现核心业务路径根本没测透。问题出在方法上AI 生成的单接口用例质量不差但缺少业务场景串联能力。我的打法是“场景驱动的分层生成”。第一步把从需求阶段得到的用户故事列表喂给 AI让它对每个故事生成主路径用例和备选路径用例——这里的主路径不是“调用接口成功返回”而是“用户从注册到完成第一笔订单”这样的端到端流第二步针对系统中已知的复杂逻辑如状态机流转、并发扣减、对账差异处理单独喂给 AI 生成边界组合用例第三步把 AI 生成的用例逐条映射到需求验收标准上形成可追溯矩阵。这套打法对团队的测试设计能力提升非常显著。过去测试同学拿到需求后第一个动作是照着字段名猜规则现在大家主动画流程图、标状态节点、列异常矩阵因为这些结构化的输入经过 AI 生成出来的用例质量远高于一句话需求生成的用例质量。换句话说AI 不仅降低了生成用例的体力成本还反向逼迫团队上游输出更结构化的需求文档。还有一个细节值得多说一句AI 生成的测试数据经常会踩到数据一致性坑。比如它生成的订单号、用户 ID 格式看着没问题但插入数据库时会撞唯一索引。建议在提示词里要求 AI “严格按照已有测试数据规范生成编号使用 TC-2025-xxx 格式”并且生成后批量跑一次 dry-run 校验唯一性。这个坑我踩过至少三次才彻底长记性。3. 实操过程与核心环节实现一个模拟项目的 AI 辅助全流程实录为了让你能直接复现这套方案我拿一个模拟项目 X——“订单中心系统重构”走一遍完整的 AI 辅助流程。这个项目规模适中包含订单创建、支付回调、库存扣减、超时取消、退款处理五个核心模块非常适合演示 AI 在 SDLC 各环节的介入方式。3.1 需求阶段实操从一段模糊描述到可评审的用户故事模拟项目 X 的初始需求描述只有一句话“用户下单时要锁库存支付超时要自动取消订单退款要回到原支付渠道。”直接拿这句话问 AI “请生成完整需求文档”大概率会得到一篇空洞的、到处是“确保系统稳定高效”之类的套话文档。我的实操做法是把这句话拆成三次对话。第一轮让 AI 列出“锁库存”“取消订单”“退款”三个动作各自的前置条件、异常场景、数据一致性要求第二轮把三轮结果合并让 AI 生成一份需求澄清问题清单我带着这份清单找业务方逐条确认第三轮把所有确认结果喂回 AI指定用户故事格式生成。这里给出一个我验证过的提示词模板你可以直接改改就能用背景这是一个订单中心系统包含订单创建、支付回调、库存扣减、超时取消、退款处理五个模块。 当前需求用户下单时要锁库存支付超时要自动取消订单退款要回到原支付渠道。 要求针对以上需求输出需求澄清问题清单每个问题需包含问题内容、涉及的业务前提、不同答案对系统设计的影响。 限制问题数量不少于15个重点覆盖并发场景、重复请求、状态一致性、金额精度四个方面。这一轮操作下来需求文档里最重要的不是功能描述而是确认过的业务规则列表比如“锁库存 30 分钟未支付自动释放”“取消订单后已锁库存需要回补”“退款必须原路退回”这些规则。这些规则才是后续所有设计、编码、测试的锚点。3.2 设计阶段实操让 AI 输出四个架构方案再做加权对比架构设计阶段我采用“多方案竞选”模式。让 AI 基于上一阶段产出的需求规则输出四种不同的技术实现方案每种方案要包含模块拆分、数据存储、接口设计、部署拓扑图和优劣分析。四份方案分别是方案 A——传统单体 关系型数据库 定时任务扫描方案 B——微服务拆分 消息队列 独立库存服务方案 C——单体架构 乐观锁库存字段 延迟消息队列方案 D——事件驱动 读写分离 分布式事务中间件。拿到四份方案后我建了一个加权评分表来筛选。评分维度包括实现复杂度、性能天花板、数据一致性保障、团队现有技术栈匹配度、未来扩展空间、运维成本每个维度按项目实际情况分配权重。这个步骤 AI 帮不了必须人来判断因为权重体现的是业务战略不是技术正确性。模拟项目 X 最终选了方案 C单体架构 乐观锁库存字段 延迟消息队列。理由很简单团队对微服务的驾驭能力一般而项目的核心是库存一致性用数据库乐观锁加延迟消息刚好能解决同时避免引入分布式事务带来的复杂度。这个选择背后有个重要认知AI 给的四份方案每一份都能工作真正的架构能力体现在选“当下最合适”而不是“技术最先进”。3.3 编码实现实操AI 按“模块级”生成代码人做“逻辑边界缝合”编码阶段我没有让 AI 一次性生成整个项目而是按模块逐个推进每个模块都走同一个流程先写接口定义和数据结构人写再让 AI 按这个契约生成实现代码AI 写最后人工补全异常分支和事务边界人补。模拟项目 X 里库存扣减这个模块是这个流程的最好示例。我先手动定义接口deductStock(orderId, skuId, quantity)指定返回值是枚举类型SUCCESS / INSUFFICIENT_STOCK / REPEAT_REQUEST然后把这个接口定义加一段库存表结构发给 AI让它生成带乐观锁的扣减逻辑。AI 生成的代码里乐观锁条件where stock quantity写得是对的但缺少事务边界内的库存回补语义——支付超时取消订单时要把扣掉的库存加回来这个关联逻辑是我在第二轮的边界缝合里补上的。这一步特别想强调AI 负责写“单点正确的实现”人负责保证“链路正确的闭环”。库存扣减单点再怎么对如果取消订单时没有触发回补整个业务链路的资金和库存账都是错的。我用了一个笨办法来保证链路闭环每次完成一个模块就手动画一张该模块涉及的链路时序图从入口事件开始标出所有分支出口逐一确认分支出口都有对应的处理逻辑。AI 生成代码的效率价值必须建立在人工链路审查不出错的基础上。3.4 测试设计实操让 AI 生成“反业务直觉”的用例测试阶段我重点提升了 AI 生成用例的“刁钻程度”。很多团队生成用例时 AI 常产出正例因为训练数据里正常的用例占多数但真正能暴露系统缺陷的往往是那些“偏离正常业务路径半步”的用例。模拟项目 X 里我让 AI 专门生成“业务规则违背型”用例效果非常惊艳。比如“下单数量为负数时系统应当报错”“支付回调重复通知两次时系统只处理一次”“订单取消时该订单已处于退款中的状态怎么处理”“库存扣减成功但订单创建失败后 1 秒内用户再次下单”等场景这类用例如果不是 AI 密集生成人工很容易漏掉。我再分享一个压缩测试成本的技巧让 AI 对生成的每条用例标注“预期触发哪一条业务规则”。这样测试执行不通过时能直接定位是规则实现缺失还是用例设计错误排障效率高很多。模拟项目 X 的测试执行中有一条用例一直失败同一订单并发发起两次取消请求系统返回了两个成功。追查发现取消订单的方法缺少幂等校验——这正好是用例设计时 AI 标的“规则 R7取消请求必须幂等”问题定位只花了几分钟放在传统流程里这种并发类缺陷可能要到线上才暴露。3.5 部署与运维实操AI 写的发布检查清单比人为拍脑袋靠谱部署发布这个环节AI 最有价值的地方是生成发布检查清单和回滚决策辅助。很多团队发版就是“测完没事就上”缺少系统性的风险评估。我让 AI 基于模拟项目 X 的变更内容生成发布检查清单包括数据库变更是否有锁表风险、是否有新增配置项需要同步测试环境、是否有接口兼容性要求、回滚脚本是否准备齐全——这份清单生成后发布评审会的效率从半小时压缩到十分钟。运维阶段我重点用了 AI 做告警噪声抑制。模拟项目 X 上线初期告警群里每天四五十条消息真正需要处理的只有三五条。我让 AI 对告警内容做聚类和根因推测把同一时间窗口内“数据库连接数上升”“订单创建超时比例升高”“CPU 使用率涨到 80%”三条告警自动归并为同一次根因事件——数据库连接池打满并且给出验证建议。AI 不背锅它只负责把线索按相关性归类呈现最终的变更决策由值班人判断。这个环节带给我的技能提升是系统性的我的运维视角不再是“盯着某个指标看”而是习惯性地把应用日志、中间件指标、业务监控数据放在一起关联分析。这种跨层级的关联分析能力正是从高级开发走向资深技术专家的必修课。4. 常见问题与排查技巧实录AI 辅助 SDLC 落地遇到的现实障碍4.1 AI 生成的代码总是“看着对跑起来错”这是所有人都会遇到的第一个坑。现象是AI 生成的函数逻辑上完整、语法上也正确但运行时报空指针、报类型错误、报数据不一致。原因是 AI 生成代码时依赖的是它对需求的“文本理解”而不是对你项目里真实数据结构和调用的“运行时理解”。我的排查套路分三步第一步把报错堆栈复制到 AI 对话里要求它先定位到具体代码行并解释为什么出错不要直接给修复代码。第二步生成修复方案时把报错代码涉及的所有相关变量定义、调用方代码粘贴给它让它基于完整上下文重写。第三步修复后的代码不是直接合并而是让 AI 同步生成一个针对该代码路径的最小复现测试先跑通复现测试再合并代码。这个流程的核心作用是把“AI 幻觉”的负面影响限制在最小范围。你无法阻止 AI 在某些情况下给出错误代码但可以建立一套“犯错—定位—复现—修复”的最小闭环把每一次 AI 的错误都转化成一个测试用例和一次团队经验积累。4.2 提示词越来越长输出质量反而下降很多人会不断往提示词里堆要求“请以专家的身份输出高质量、生产级的代码同时考虑性能、安全、可维护性、可扩展性并且……”结果生成内容越来越泛越来越模板化反而失去针对性。我自己调整之后的核心原则是“提示词瘦身 分轮对话”。第一轮只给任务背景和当前输入让 AI 自主判断该输出什么格式第二轮针对第一轮输出的缺点给具体修改方向比如“库存扣减的乐观锁并发控制你没覆盖请补上”第三轮再做格式和风格统一。单轮提示词控制在 200 字以内超过就拆分任务。经验是AI 对“角色设定”和“输出格式”的遵从度很高但对“性能优化的具体建议”这类结果型要求的遵从度很低。让 AI 在每一轮专注解决一个具体问题比把它逼成全能选手有效得多。4.3 团队成员的 AI 使用水平参差不齐产出风格割裂这点在真实团队里特别常见——有人用 AI 用得飞起有人还处于复制粘贴报错信息的阶段而且两派人产出的代码风格差异巨大。前者生成的代码大量使用高级语法后者基本是手写裸代码review 时两边互相看不惯。我的处理方式是制定一份简洁的“AI 辅助开发约定”把强制规则写清楚AI 生成的代码必须符合项目已有的代码风格不引入未在项目中使用的第三方库所有 AI 生成的复杂逻辑必须附带注释说明思路来源AI 生成的代码必须经过与手写代码同等严格的评审流程。约定不需要长篇大论但必须明确“AI 输出是初稿人不 review 不得合入”这条底线。另外一个有效配置是让团队里 AI 用得最好的人每周做一次“提示词复盘分享”把自己压箱底的提示词模板和踩坑记录共享出来把个人能力转化为组织能力。我观察到一个明显规律凡是坚持做分享的团队AI 辅助开发的整体产出质量会稳定爬升不做分享的团队要么永远停留在几个高手自己用 AI 的局面要么被水平低的人产出的劣质 AI 代码拖累整体节奏。4.4 硬编码的业务逻辑没有走 AI走下坡路的反而是设计能力这条可能出乎很多人的意料。我原本以为“让 AI 处理所有重复性工作人的设计能力应该会越来越多地用在创造性工作上”实际操作下来发现如果长期只让 AI 做重复性编码人的架构设计能力不仅没提升反而变钝了。原因很简单——高级的设计判断力来自低级编码中积累的细节感知。比如你会从写接口参数校验的过程中意识到参数校验策略影响接口的幂等设计会从调试并发库存扣减的过程中理解分布式锁的粒度选择这些微观体感是设计判断力的燃料。当 AI 把这些环节全部“代劳”之后你没有了产生微观体感的练习机会设计能力就成了空中楼阁。我的应对策略是“AI 参与但人复述”的机制每完成一个模块必须自己用结构化语言把该模块涉及的三个关键设计决策复述一遍包括这个决策的背景、备选方案、为什么这样选。这个动作相当于替自己建一份“设计决策日志”既能巩固微观体感又能产出高质量的项目文档素材。强迫自己做这个动作之后我明显感觉到自己的设计复盘速度和质量都提升了一个档次团队新人也能通过阅读决策日志更快建立全局认知。4.5 问题排查速查表现象根本原因快速处理方案AI 生成的代码运行时抛异常运行时上下文信息缺失粘贴完整调用链和数据结构重新生成AI 输出空泛、套话多提示词缺少具体约束缩减提示词指定输出格式和反向要求生成的测试覆盖跑偏用例没有映射业务规则让 AI 标注每条用例触发的业务规则编号团队产出风格混乱缺少 AI 使用规范制定强制约定风格一致、review 必走、复杂逻辑必注释设计能力不升反降AI 代劳了微观体感练习建立“设计决策日志”人复述关键决策关键时刻排查口诀人机协作出问题先想“上下文够不够”再想“边界条件是啥”最后想“是不是我把决策权也让出去了”。这三问能解决 80% 的 AI 辅助开发现场问题。5. AI 驱动 SDLC 技能提升的长期实践心得项目做完把整套方法论沉淀下来之后我最想单独拿出来说的是几个反直觉的体会。第一AI 辅助的 SDLC 技能提升最核心的产物不是效率而是“人的判断密度”。同样一个项目传统模式下你需要做十次关键判断AI 辅助模式下你做的关键判断数量可能翻倍。每一次判断、每一轮对 AI 输出的筛选与修正都是对你专业技能的一次打磨。效率提升只是附带结果判断力的增长才是真正的复利。第二工具选择非常重要但比工具更重要的是团队对“人机边界”的统一认知。我见过用免费工具用出极高效率的团队也见过全上最好的商业工具但仍然混乱的团队差异不在于工具本身而在于每个人的认知是否对齐AI 是强大的初稿生成器是永不疲倦的代码评审员是知识渊博的多个专家顾问但不是最终责任人。最终责任人永远是人。第三AI 辅助开发的技能提升有一个隐藏加速器把 AI 当学生教。当你把一个业务场景讲给 AI 听并且要让它理解到能产出合格方案的程度时你实际上是在被迫精简自己的表达、补全自己的逻辑漏洞、审视自己在业务理解上的空白区域。这种“教中学”的机制是传统开发模式下很难获得的成长路径。如果让我给刚起步的团队或开发者一个最实用的建议我会说从你日常最头疼的那个 SDLC 环节开始不要一上来就搞全面改造。如果你最烦写测试用例就先让 AI 帮你生成用例如果你最怕画架构图就先让 AI 帮你出初稿如果你觉得需求沟通总扯皮就先让 AI 帮你列澄清问题。先把一个环节跑顺尝到甜头建立信心再逐步向上下游延伸。我就是在“测试用例生成”这个单点突破之后才决定把整个 SDLC 流程全部重过一遍的。最后还有一个小技巧算是送给读者的彩蛋每次做需求澄清或架构评审前我会先把上一轮 AI 生成的结果打印出来用笔在纸质文档上圈出那些我觉得“不太对劲但说不清哪里不对劲”的段落然后把圈出来的内容再发给 AI。神奇的是这个动作反复几次之后我对 AI 输出内容的“直觉预警”能力明显变强了——一圈一个准那些被我圈出来的部分大概率真的存在问题。这个习惯我保留到了现在算是人机协作时代培养专业直觉的一个土办法但确实很管用。
