CS146S week6-9 ai安全，审查，开发与维护
introducing the potential and harm of ai safety, checking, developing and ensuring
views
| comments
cs146s week6-9的内容比较宽泛，从安全防范到代码审查，再到应用开发的范式转变(课程上介绍了相应的warp,graphite,seeslope，bolt几个工具)，但是不可否认的是，ai正在改变整个软件生态
AI safety#
传统的漏洞检测技术（如 SAST 分析应用程序安全、DAST 模拟攻击、SCA 分析外部依赖查找漏洞）在常规开发中已经非常成熟。然而，随着 AI 代理的引入，我们面临着全新的攻击。 现在的新的可能的attack:
- AI agent攻击：prompt injection(指令导致ai偏离预期)，tool misuse(滥用集成的工具)，code attack(授权没有做好)
，非确定性分析(多次运行效果不同)，上下文腐烂(难以定位问题，而且不是所有的context是平等的) 未来展望：
- 如何减少误报和幻觉，检测LLM生成的补丁有无问题，道德伦理问题(AI生成的补丁应该如何负责)，如何去验证呢
AI代码审查#
代码审查是软件工程的生命线，缺乏严格审查的代码库最终都会演变成难以维护的“屎山”。
代码审查原则#
审查的核心要素（按重要程度自下而上）：
- 逻辑与正确性：例如严格区分和审查
is与== 的使用场景 - 可读性与可维护性：代码编写需具有良好的分块与结构，便于人类阅读。
- 性能优化：例如在查找操作中优先使用
Set以提升速度。 - 安全性：严格避免使用任何带有潜在危险的代码模式。如下图
- 使用最佳的实践
从下到上越来越重要
AI in 代码审查#
- 市场玩家：目前市场上已经涌现出如 Graphite, Greptile, Coderabbit, Claude Code / Codex 等众多玩家。AI 的介入带来了审查效率的显著提升、开发者认知负荷的降低，并能够基于对代码库的整体理解实现持续改进。
- AI 的能力边界：
- AI 能捕捉：最佳实践、代码整洁度、文档、风格、边缘情况、性能问题、安全漏洞和 Bug。
- AI 难以捕捉（目前）：范围蔓延 (Scope Creep)、个人偏好 (Preference)、部落知识 (Tribal Knowledge) 以及意外的代码行为。
- 人机交互：人类不希望从 LLM 那里接收关于风格的琐碎建议，也不希望把时间浪费在给 LLM 写这种建议上 目前技术上仍有局限（如难以捕捉特定的编码习惯或复杂的仓库逻辑），但我们可以通过提升外循环 (Outer loop) （作者 -> 测试 -> 审查 -> 合并 -> 部署）中最大化ai的价值，但是要用到什么程度，就要看你的产品需求了。
AI APP 开发#
现在开发一个应用越来越容易了
- prompt即应用，工程师的角色扩展，门槛的降低 比如app builder architecture可以直接使用webcontainer以及prompt工程进行架构 新的隐患：
- 代码修复困难：由 AI 生成的庞大代码，一旦出现深层逻辑错误，人工介入修复的成本极高。
- 复杂度天花板：纯 AI 生成的应用到底能支撑多高的业务复杂度仍是未知数。
- 应用同质化与安全问题：模式化的生成容易导致产品千篇一律，且存在潜在的安全漏洞。
未来的应用开发工作流（以 v0 为例）： 现代 AI 代理工作流已经涵盖了：意图理解 -> 上下文组装（收集现有代码组件） -> 生成代码 -> 验证测试 -> 人在回路 (Human-in-the-loop) 审查与反馈。
LLM在编程时的局限性
- LLM概率模型，但是需要确定性的框架
- 知识过时问题如何解决：流式操纵：直接建立子系统在到达用户前打补丁
- sft&&rl去加 Future
- 工具生态：目前的 AI 开发工具正处于爆发期，分为代码助手（如 GitHub Copilot）、前端构建器（如 v0, Lovable）和可视化开发平台等。
- 核心差异化：未来的关键区别在于端到端的工作流 (End-to-end workflows)，即 AI 不仅是自动补全建议，而是处理从测试、部署到监控的整个生命周期。
- 实际影响：初创公司可以在几天而非几个月内发布 MVP；企业能够更现代化地处理遗留系统
AI 维护#
ai未来可能会转向维护的工作，减少做苦力活的内容， 当前核心痛点：软件工程中的“苦力活” (Grunt Work)**
- 70/30 比例：软件工程师实际上有 70% 以上 的时间花在“苦力活”上（如查询日志、建立上下文、收集证据、协调沟通、合规性检查、待命值班），只有不到 30% 的时间用于“创造性工作”（如解决问题、优化、设计决策） 这会让人非常==疲惫==，但是生产级的ai
- prompt不够，还需要domain knowledge
- 上下文窗口的限制，mcp，eval不容易 希望未来的话，软件工程会转向纯纯的代理
总的来说，ai in software深入下去还是有更多的工程管理上的内容，相信等到我未来进行一些大型项目时，会有更多的体会