大项目里来了一个新需求，加一个新功能的工作流是怎样的？

先这样答

我会先拆需求和评估影响面，再定义评测标准，然后做最小改动，经过灰度验证后上线监控。大项目里加功能，不能只看新功能能不能跑通。我会先弄清需求要解决什么问题，再判断它会动到哪些模块。对可能受影响的存量功能，我也会提前列出检查范围。这样实现时知道该改哪里，验证时也知道不能只测新功能。

动手实现前，我会先给新功能建评测集，明确什么结果算做对。评测不能等代码写完才补。否则功能看起来可用，却没有清楚的标准判断它是否满足需求。我也会根据前面的影响面评估，确定哪些原有表现需要在回归时检查。这个步骤把需求、实现和验证对齐，也能避免只凭一次演示判断效果。

实现时我会控制改动范围。提示词层能解决的问题，就不动代码；确实需要改代码，再针对相关模块改。完成后先跑评测集回归，再用小流量做灰度验证。上线后，我会同时看新功能指标和存量指标。新功能表现正常，不代表其他地方没有被改坏。整个流程的重点，是先定义做对的标准，并始终记住改动可能影响哪里。

面试官会怎么追问

• 「为什么要先建评测集，不能做完再测吗？」 先建评测集，才能在实现前说清楚什么叫做对。做完再想标准，容易把已经做出的结果当成正确结果。评测先行也让后续回归有明确依据。
• 「你怎么判断该改提示词还是改代码？」 我会先看需求落在哪些模块，再判断提示词层能否满足评测标准。如果提示词层能解决，就不扩大代码改动。只有它解决不了时，才修改相关代码，并检查可能受影响的原有功能。
• 「新功能评测通过了，为什么还要灰度和看存量指标？」 评测集通过，只说明它达到了事先定义的标准。小流量灰度还要验证上线后的表现。监控也不能只看新功能；我会同时看存量指标，确认这次改动没有影响别处。

回答的坑

• 只说开发、测试、上线，却说不清先用什么标准判断新功能做对了。
• 只验证新功能，不评估受影响的模块，也不看上线后的存量指标。