DevCN
菜单
社区成员个人主页
成员
DEV CN / 成员主页

宋国卿

查看宋国卿发布的技术文章、关注圈子与公开讨论。

242技术文章207关注圈子841圈内发布0关注者
COMMUNITY POSTS

交流圈发布内容

作者在不同技术圈子中的观点与讨论

1
# 求职与面试

团队要落地 AI 编码助手,你会怎么推动?

分四步:①先摸底——哪些环节最痛、哪些人愿意当先行者,不搞一刀切;②定规范——明确什么场景可用、什么场景禁用(核心业务、支付、安全相关),建立审查红线;③小步试点 + 收集数据——选一个团队跑 2-4 周,量化前后对比;④沉淀经验——把好的提示词、审查 checklist、踩坑记录沉淀成团队知识库,再逐步推广。落地关键是'让人愿意用'而不是'逼人用'。

2
# 求职与面试

你如何评估一个 AI 工具的引入是否值得?

用 ROI 思维而不是'跟风':先明确我们要解决的痛点(提效?降本?质量?),再小范围试点(选 1-2 个团队/项目),设定可量化指标——提测通过率、需求交付周期、bug 率、开发人天,跑一段时间对比基线。同时评估成本:订阅费、学习成本、安全合规风险、对代码质量的长期影响。数据说话,值得才规模化,不值得就果断停。

3
# 求职与面试

你会让 AI 参与代码评审吗?为什么?

会,但定位是'辅助者'不是'决定者'。AI 做 review 的优势是快、覆盖面广、不会累,能快速发现风格问题、重复代码、明显 bug;但它不懂业务上下文、不懂团队的历史决策、更不会为结果负责。所以我的做法是:AI 做第一遍静态扫描,人来审核它没发现的业务逻辑问题和它的判断本身,最终评审结论由人拍板。

4
# 求职与面试

AI 代码不符合公司规范和架构时你怎么处理?

先明确规范本身:如果公司有清晰的编码规范和架构约束,就把它们写进提示词并要求遵守;如果规范缺失,我会牵头和团队一起把规范沉淀成文档和 lint 规则,让 AI 自动被约束。落地层——用统一的格式化工具、linter、代码评审流程兜底,无论代码来源是谁,都过同一道门。规范是团队的,不是某个人临时判断的。

5
# 求职与面试

你会怎么设计提示词让 AI 输出更好的代码?

提示词里给足'约束条件'而不是'模糊期望':①背景与目标——这个模块给谁用、解决什么问题;②技术栈与规范——语言、框架、命名、分层要求;③边界与反例——明确不要做什么、哪些情况要特殊处理;④输出格式——是否要注释、要单测、要文档。我还会用'角色+场景+验收标准'的结构,并让它先给方案再写码,避免一步到位跑偏。

6
# 求职与面试

你如何让 AI 成为提效工具,而不是依赖?

守住三条底线:①核心设计和判断永远自己做——AI 只负责执行和初稿;②所有产出必须能解释清楚——不理解就绝不提交,防止'黑盒依赖';③持续保持手写基本功——定期手写核心算法、从零搭模块,防止能力退化。我会把 AI 当成'让同样时间产出更多'的工具,但确保离开它我依然能独立把事做成。

7
# 求职与面试

AI 生成的代码出 bug,你会怎么排查?

和排查普通 bug 一样,不预设来源:先复现,再二分定位,看错误堆栈、日志、监控;重点检查 AI 最容易错的地方——边界条件、类型、API 用法、并发、配置。定位后分析'是需求理解错、还是实现错',修正后补上回归测试,并把这条经验沉淀进团队 checklist,避免同类问题再犯。责任不在'是 AI 写的',而在'我没把关好'。

8
# 求职与面试

你能分辨 AI 代码和人类代码吗?为什么重要?

很多时候能看出倾向:AI 代码通常风格统一、注释完整、但容易出现'过度通用、没有考虑真实业务特例'的特征,也常缺少对异常边界和业务上下文的细腻处理。能分辨的意义不在于'抓 AI',而在于提醒自己——这种'标准答案'恰恰需要人用业务经验去审视哪里不对。真正重要的是审查质量,而不是来源。

9
# 求职与面试

如何防止 AI 生成的代码引入安全隐患?

从源头和末端双管齐下:源头——提示词里明确要求'遵循 OWASP 安全规范、不硬编码密钥、做输入校验';末端——强制走安全审查流程:静态扫描工具、依赖漏洞扫描、人工 review 重点关注鉴权/注入/敏感信息,关键路径加安全测试。再就是原则:AI 生成的代码和人类代码一样进 CI/CD,过同一套安全门,没有特权通道。

10
# 求职与面试

你踩过 AI 生成代码的哪些坑?

(示例)最典型的有三类:①'幻觉式正确'——API 名、方法签名看着对其实不存在,编译才暴露;②边界缺失——没处理空值和异常,生产环境一炸;③过时写法——用了一个已被弃用的库,埋下隐患。吃过的教训让我养成习惯:AI 给的代码一律当'待验证的草稿',跑测试、查文档、看真实调用来验证,而不是凭'它看起来对'就提交。