CS146S课程内容详细学习¶

原始文件: CS146S课程内容详细学习.docx (42 KB) — 位于 C:\Users\24835\实习积累知识集合

CS146S: The Modern Software Developer 斯坦福大学 • Fall 2025 Week 1 核心概念 - LLM 内部原理：Transformer 架构（Attention 机制、自注意力）、Tokenization（将文本拆成 token）、Pre-training + Fine-tuning + RLHF。LLM 不是“懂”语言，而是统计预测下一个 token 的概率模型。 - Prompt Engineering：通过精心设计的输入，让 LLM 输出高质量、可控结果。核心技巧：Zero-shot / Few-shot / Chain-of-Thought (CoT) / Self-Consistency / ReAct（Reason + Act）。为什么重要？所有后续 Agent、IDE、工具都依赖“和 LLM 有效沟通”。

Self-Consistency：从输出中多次采样（通常使用 CoT），并汇总最常见的结果。通过对不同的推理路径进行采样，以模型集成的形式减少幻觉/错误答案。 Tool Use：允许LLM依赖其需要交互的外部系统减少幻觉并赋予LLM自主性的最重要技术之一。 RAG： - Infuse the LLM with contextual data - Keeps LLMs up-to-date (without retraining) - Faster iteration - You get interpretability and citations for free - Reduces hallucinations

提示工程的核心定义与重要性- Google Cloud Prompt 最佳实践 - 提示工程是一门通过设计高质量提示来引导 LLM 生成准确、相关、安全输出的技能。 - 随着 LLM 在产品与工作流中的普及，提示工程成为人与 AI 高效协作的关键能力。 - 高质量提示能显著提升模型性能、减少偏差、增强可控性与用户体验。 🧩 什么是提示（Prompt） - 提示是用户给模型的输入，可以是问题、指令、代码、示例、上下文等。 - 提示的质量直接决定输出质量。 🛠️ 提示工程的关键要素 - 提示格式：自然语言、命令式、结构化字段等，不同模型偏好不同格式。 - 上下文与示例：提供背景信息、风格示例、输入输出示例可显著提升效果。 - 微调与调整：通过迭代修改提示持续优化结果。 - 多轮对话设计：让模型保持上下文，提升交互体验。 🧱 常见提示类型 - 零样本提示（Zero-shot）：直接提问或给指令。 - 单样本 / 少样本提示（One-shot / Few-shot）：提供示例帮助模型理解任务。 - 思维链提示（CoT）：让模型分步骤推理。 - 零样本 CoT：在零样本基础上要求模型“展示推理过程”。 📚 提示工程的主要应用场景 1. 语言与文本生成 - 创意写作、摘要、翻译、对话模拟等。 2. 问答 - 开放式问题、精准检索、选择题、假设性问题、观点类问题。 3. 代码生成 - 代码补全、转换、优化、调试。 4. 图像生成与编辑 - 逼真图像、艺术风格、抽象图像、图像修改。 🧭 高质量提示的六大策略 1. 设定明确目标 - 指定动作、长度、格式、受众。 2. 提供上下文与背景 - 加入事实、数据、来源、定义。 3. 使用少样本示例 - 展示风格、详细程度、输入输出对。 4. 具体明确 - 避免模糊表达，量化需求，拆解任务。 5. 迭代与实验 - 调整措辞、长度、细节，持续优化。 6. 利用思维链 - 要求逐步推理、解释思路、遵循逻辑顺序。 🌟 提示工程带来的价值 - 更高的模型性能：输出更准确、相关、信息丰富。 - 减少偏见与风险：通过输入控制降低不当内容。 - 更强的可控性：让模型行为更可预测。 - 更好的用户体验：交互更自然、结果更稳定。 🧭 Google Cloud 相关资源（页面内容） - Vertex AI、Model Garden、AI API - 提示设计文档、示例、课程 - 新用户可获得 $300 额度用于体验

How OpenAI uses Codex：如何布置AI 代码助手团队落地方案？ Codex 在 OpenAI 内部的总体定位 Codex 已成为 OpenAI 多个技术团队（安全、产品工程、前端、API、基础设施、性能工程等）的日常工具，用于加速工程任务、提升代码质量、减少复杂度，并在高压场景（如事故响应）中提高效率。 🧩 七大核心使用场景 1. 代码理解（Code Understanding） - 快速熟悉陌生代码区域，用于 onboarding、调试、事故排查。 - 自动定位核心逻辑、模块关系、数据流、架构模式与缺失文档。 - 在事故响应中快速追踪组件交互与故障传播路径。 2. 重构与迁移（Refactoring & Migrations） - 批量更新跨文件/跨包的代码模式。 - 替换旧模式、拆分大模块、清理技术债。 - 自动生成 PR，显著减少重复劳动。 3. 性能优化（Performance Optimization） - 分析慢路径、内存热点、重复昂贵操作。 - 建议更高效的循环、缓存策略、批处理方式。 - 帮助识别风险模式与潜在回归点。 4. 提升测试覆盖率（Improving Test Coverage） - 自动生成单测、集成测试、属性测试。 - 覆盖边界条件、异常路径、空输入等容易遗漏的情况。 - 可在低覆盖模块上自动生成可运行的测试 PR。 5. 提升开发速度（Increasing Development Velocity） - 快速生成脚手架、API stub、配置文件、埋点代码。 - 在发布前处理大量“小但必要”的任务。 - 将产品需求或用户反馈直接转化为初版代码。 6. 保持开发流畅（Staying in Flow） - 捕获未完成工作、将笔记转为原型、生成可稍后处理的任务。 - 在碎片化日程中减少上下文切换成本。 7. 探索与创意（Exploration & Ideation） - 生成多种实现方式、验证设计决策、探索新模式。 - 查找类似 bug、识别潜在回归点。 🛠️ Codex 的最佳实践 ⭐ 1. Ask Mode → Code Mode 的两步工作流 - 先让 Codex 生成实现计划，再让其写代码。 - 有助于减少错误、保持任务范围清晰。 ⭐ 2. 持续优化 Codex 的运行环境 - 设置启动脚本、环境变量、网络访问。 - 通过迭代修复构建错误，显著降低 Codex 的失败率。 ⭐ 3. 像写 GitHub Issue 一样写 Prompt - 包含文件路径、组件名、diff、文档片段。 - 使用“按 X 模块的方式实现”这种模式提升一致性。 ⭐ 4. 使用 Codex 任务队列作为轻量 backlog - 捕获灵感、边缘任务、顺手修复。 - 不必一次生成完整 PR，可随时回头处理。 ⭐ 5. 使用 AGENTS.md 提供持久上下文 - 记录命名规范、业务逻辑、依赖、已知坑。 - 让 Codex 在多次任务中保持一致性。 ⭐ 6. 使用 Best-of-N 提升输出质量 - 同时生成多个版本，挑选最佳或组合。 🔭 未来展望 Codex 仍处于研究预览阶段，但已显著改变 OpenAI 的软件开发方式。随着模型能力增强与更深的工作流集成，Codex 将承担更大规模的任务，进一步提升开发效率与代码质量 AI 代码助手团队落地方案（基于 OpenAI Codex 实战经验） 1. 落地目标与团队定位 AI 代码助手的核心价值是让工程团队更快、更稳、更一致地交付软件。结合文档内容，AI 助手应承担三类职责： - 加速工程效率：减少重复劳动、自动生成脚手架、快速补齐测试、辅助重构。 - 提升代码质量：识别风险模式、优化性能、统一风格、减少回归。 - 降低复杂度成本：帮助理解大型系统、跨模块追踪逻辑、支持事故响应。这意味着 AI 助手不是“写代码工具”，而是工程团队的第二大脑。 🧩 2. 团队级工作流设计（核心七大场景）以下每个场景都来自 PDF 的真实使用案例，并转化为可执行 SOP。 2.1 代码理解（Code Understanding）适用于：Onboarding、调试、事故排查来源：文档 Use Case 1 团队 SOP： - 在 On-call 时，将 stack trace 直接贴给 AI，让它定位逻辑入口。 - 让 AI 绘制模块交互图、数据流摘要。 - 让 AI 搜索“类似问题可能出现在哪些文件”。团队收益：减少 50% 以上的排查时间，降低资深工程师的知识垄断。 2.2 重构与迁移（Refactoring & Migrations）来源：Use Case 2 团队 SOP： - 让 AI 扫描旧模式 → 输出影响分析 → 自动生成 PR。 - 批量替换 callback → async/await、旧 API → 新 API。 - 拆分大文件、生成对应测试。团队收益：跨文件重构从“几天”缩短到“几小时”。 2.3 性能优化（Performance Optimization）来源：Use Case 3 团队 SOP： - 让 AI 扫描重复昂贵操作（DB 调用、循环、序列化）。 - 让 AI 提出缓存策略、批处理方式。 - 让 AI 标记潜在回归点或风险模式。团队收益：性能调优从“凭经验”变成“系统化扫描”。 2.4 测试覆盖率提升（Improving Test Coverage）来源：Use Case 4 团队 SOP： - 让 AI 自动生成单测、集成测试、属性测试。 - 让 AI 扫描低覆盖模块并生成可运行的测试 PR。 - 让 AI 自动补齐边界条件（null、空输入、极值）。团队收益：测试覆盖率提升不再依赖“自觉性”。 2.5 开发速度提升（Increasing Development Velocity）来源：Use Case 5 团队 SOP： - 让 AI 生成 API stub、目录结构、配置文件、埋点代码。 - 让 AI 将产品需求直接转成初版实现。 - 让 AI 处理 backlog 中的小任务。团队收益：工程师在会议中也能“异步产出”。 2.6 保持开发流畅（Staying in Flow）来源：Use Case 6 团队 SOP： - 让 AI 总结当前文件，方便第二天继续。 - 让 AI 生成 TODO stub，减少上下文切换。 - 让 AI 将 Slack/Issue 转成可执行任务。团队收益：碎片化工作不再导致效率崩塌。 2.7 探索与创意（Exploration & Ideation）来源：Use Case 7 团队 SOP： - 让 AI 提供多种架构方案并比较 trade-off。 - 让 AI 找出类似 bug 的潜在位置。 - 让 AI 重写代码为不同风格（函数式、无副作用）。团队收益：工程师从“写代码”转向“做决策”。 🛠️ 3. 团队级最佳实践体系（来自 OpenAI 内部经验）这些最佳实践来自 PDF 的 Best Practices 部分，我将其转化为团队可执行规范。 3.1 Ask Mode → Code Mode 两步工作流团队规范： - 大任务必须先让 AI 生成“实现计划”，再让它写代码。 - PR 级任务必须拆成多个 Ask → Code 的小任务。效果：减少错误、提升一致性。 3.2 优化 AI 的运行环境团队规范： - 为 AI 配置启动脚本、环境变量、依赖。 - 每次构建错误都要反馈给 AI 环境配置。效果：显著降低失败率。 3.3 像写 GitHub Issue 一样写 Prompt 团队规范： Prompt 必须包含： - 文件路径 - 组件名 - diff - 文档片段 - “按 X 模块的方式实现” 效果： AI 输出质量提升 2–3 倍。 3.4 用 AI 任务队列作为轻量 backlog 团队规范： - 所有“顺手修复”“灵感任务”都丢给 AI。 - 不要求一次生成完整 PR。效果：减少 backlog 堆积。 3.5 使用 AGENTS.md 提供持久上下文团队规范： AGENTS.md 必须包含： - 命名规范 - 业务逻辑 - 已知坑 - 依赖关系效果： AI 在多次任务中保持一致性。 3.6 使用 Best-of-N 提升输出质量团队规范： - 复杂任务必须生成多个版本并人工挑选。效果：输出质量显著提升。 🧱 4. 团队落地路线图（4 周）第 1 周：基础设施搭建 - 配置 AI 环境（依赖、启动脚本、权限） - 创建 AGENTS.md - 制定 Prompt 规范第 2 周：核心场景试点 - 选择 2 个团队（如前端 + 后端） - 试点 3 个场景：代码理解、重构、测试生成第 3 周：工作流集成 - 将 AI 任务队列接入 GitHub/GitLab - 建立 Ask → Code 工作流 - 建立 AI 生成 PR 的 review 规范第 4 周：团队级推广 - 组织内部分享会 - 统一最佳实践 - 设立 AI 代码质量指标（如 PR 生成率、测试覆盖率提升） 🧩 5. 角色分工（适用于你们团队） 🔭 6. 成熟度模型（评估团队是否真正落地） Week 2&3: 核心概念 - Agent 架构：LLM + Memory + Tools + Planner + Executor。 - Tool Use & Function Calling：LLM 调用外部函数的 JSON Schema。 - MCP (Model Context Protocol)：2025 新协议，标准化 Agent 与外部工具的安全交互（STDIO/HTTP 传输、工具定义、认证、Registry 发现）。比传统 API 更安全（不暴露密钥、不让 Agent 直接联网）。

Advanced Context Engineering for Coding Agents 下面是对你当前页面的结构化要点总结，所有内容均基于你浏览的页面本身 github.com。 🧭 核心论点：AI 在复杂代码库中不是“更聪明就能解决”，而是“上下文工程（Context Engineering）决定成败” 文章的中心思想非常明确： - AI 在大型、复杂、老旧（brownfield）代码库中表现差，不是因为模型不够强，而是因为上下文管理做得不好。 - 想让 AI 在真实工程环境中可靠工作，需要把“上下文工程”当成一门严肃的工程学科。 - 作者团队通过“频繁、有意的压缩（Frequent Intentional Compaction）”让 Claude Code 在 30 万行 Rust 项目中稳定产出高质量 PR。

🧩 为什么 AI 在真实代码库中表现糟糕？文章引用了 Stanford 研究与行业经验，指出几个根本原因： - AI 生成的代码常常是“上周 AI 写的垃圾的重写版”，形成 tech debt factory。 - AI 在绿地项目表现好，但在大型成熟代码库中会让生产力下降。 - 复杂系统中，AI 很容易迷失上下文、产生错误推断、或在错误方向上越走越远。这些问题不是模型能力问题，而是上下文输入质量问题。 🧱 关键理念：上下文窗口是唯一的控制杠杆 LLM 是无状态函数，每一步都是： Context Window → Stateless Function → Next Step 因此： - 上下文内容的正确性、完整性、噪声控制、轨迹（trajectory）决定了最终质量。 - 最糟糕的情况排序是： - 错误信息 - 缺失信息 - 噪声过多

🔧 传统做法为什么不够？文章批判了常见的“天真用法”： - 把 AI 当聊天机器人，来回对话直到跑偏 - 上下文爆掉后重新开一个 session - 依赖“更强模型”而不是更好流程这些方式无法在复杂系统中稳定工作。 🧠 解决方案：Frequent Intentional Compaction（频繁、有意的压缩）这是文章的核心贡献。目标 - 让上下文利用率保持在 40–60% 区间 - 让每一步都基于最新、最准确、最紧凑的上下文 - 让 AI 始终“知道自己在做什么” 方法整个开发流程被重构为三个阶段： 1) Research（研究） - 让 AI 探索代码库、定位相关文件、理解数据流 - 使用子代理（subagents）避免污染主上下文 - 输出结构化研究文档（原因、位置、依赖、潜在方案） 2) Plan（计划） - 基于研究生成精确的实现计划 - 包含：修改哪些文件、如何修改、测试策略、验证步骤 - 计划是“源代码”，代码是“编译产物” 3) Implement（实现） - 按计划逐步执行 - 每完成一个阶段就重新压缩上下文，把当前状态写回计划文档 - 避免上下文漂移

🧩 Subagents（子代理）的作用：不是角色扮演，而是上下文隔离子代理用于： - 搜索文件 - 阅读大文件 - 生成摘要 - 预处理信息主代理只接收“压缩后的结构化结果”，避免上下文污染。 🧪 实战案例：在 30 万行 Rust 项目中一小时修 bug、7 小时写 3.5 万行代码文章提供了两个真实案例：案例 1：BAML 代码库（300k LOC） - 作者完全不懂 Rust - 1 小时内产出可合并 PR - 第二天被维护者直接批准案例 2：复杂功能（取消机制 + WASM 支持） - 估计需要资深工程师 3–5 天 - 作者与伙伴用 7 小时完成 35k LOC - 其中一个 PR 已合并，另一个有可运行 demo 这些成果都依赖“研究 → 计划 → 实现”的上下文工程流程。 🧨 失败案例：为什么有时仍然会失败？文章坦诚指出： - 在 parquet-java 中尝试移除 Hadoop 依赖失败 - 原因是研究阶段没有深入依赖树 - 复杂问题仍然需要领域专家参与 - AI 不是魔法，流程不能替代专业知识

🧠 高杠杆点：人类应该审查研究与计划，而不是代码作者强调： - 坏代码只影响一处，坏计划会导致成百上千行坏代码。 - 坏研究会导致整个方向错误。 - 因此人类的注意力应该集中在： - 研究文档 - 实现计划 - 测试策略 - 而不是逐行审查 AI 写的代码这也是为什么“spec-first”是未来趋势。 🧭 团队协作：如何保持 mental alignment（心智对齐）随着 AI 产出更多代码： - 每个工程师对代码库的熟悉度会下降 - 传统 code review 无法跟上 - 因此需要新的协作方式： - 研究文档 - 实现计划 - 结构化上下文这些文档成为团队共享的“源代码”。 🔮 未来趋势：模型会被商品化，真正的难点是团队流程文章最后的观点： - 模型会越来越强，但不是核心竞争力 - 真正的竞争力是团队是否掌握上下文工程与 agentic workflow - 未来 AI 会写 99% 的代码 - 团队协作、流程、上下文管理将决定生产力差距

如果你愿意，我可以把这篇文章进一步转写成适合放进你 Obsidian 的知识卡片（含摘要、要点、行动项、Dataview 属性），让它成为你知识库中的一篇高价值笔记。核心观点：工具质量决定 Agent 上限文章的中心思想是：LLM Agent 的能力上限，取决于你为它设计的工具是否“对 Agent 友好（ergonomic）”。传统 API/函数的设计思路不再适用，必须围绕“非确定性系统如何理解、选择、组合工具”重新设计。 🛠️ 如何构建高质量工具（方法论） 1. 快速原型 → 本地测试 - 先快速搭建工具原型（MCP server / DXT）。 - 在 Claude Code 或 Desktop 中直接连接测试。 - 给 Claude 提供相关 SDK / API 的 LLM-friendly 文档（如 llms.txt）。 2. 构建系统化评估（Evaluation） - 生成大量真实世界任务（非玩具示例）。 - 每个任务包含 prompt、期望结果、可选的预期工具调用。 - 任务应复杂、跨多步、多工具调用。强任务示例： - 安排会议 + 附件 + 会议室预定 - 调查支付异常 + 关联用户 - 生成客户留存方案（含原因分析）弱任务示例： - 简单查找、简单搜索、单步操作 3. 运行评估（Agentic Loop） - 每个任务用一个 agent 循环执行（LLM ↔ 工具）。 - 收集： - 准确率 - 工具调用次数 - token 消耗 - 错误率 - 工具调用路径 4. 分析结果（重点：看 agent 哪里“卡住”） - 阅读 agent 的 reasoning / CoT（或 interleaved thinking）。 - 关注 agent 没说出来的问题（遗漏、混乱、错误调用）。 - 观察工具调用模式，判断是否需要合并工具或优化参数。 5. 与 Agent 协作改进工具 - 把评估 transcript 扔给 Claude Code，让它自动优化工具实现与描述。 - Anthropic 内部实践表明：Claude 能显著提升工具质量，甚至超过“专家手写版本”。

🧩 高质量工具的设计原则 1. 选择正确的工具（少而精） - 工具不是 API 的简单包装。 - 避免返回大量无关数据（LLM 的 context 是稀缺资源）。 - 优先构建“高价值工作流工具”，而不是“低层 API 工具”。示例： - 用 schedule_event 代替 list_users + list_events + create_event - 用 search_logs 代替 read_logs - 用 get_customer_context 代替多个分散查询 2. 清晰的 Namespacing - 工具可能来自多个 MCP server，必须避免混淆。 - 按服务或资源命名，如： - asana_search - asana_projects_search - jira_search 3. 返回“高信号”上下文 - 避免 UUID、低层字段（mime_type、256px_image_url）。 - 优先自然语言字段（name、image_url、file_type）。 - 可提供 response_format = concise | detailed 控制返回量。 4. 优化 token 效率 - 分页、过滤、范围选择、截断。 - 工具错误信息必须“可操作”，而不是报错堆栈。 5. Prompt-engineering 工具描述 - 工具描述是最强的“隐形提示”。 - 明确输入输出、参数含义、边界条件。 - 小改动可能带来巨大性能提升（文中提到 SWE-bench Verified 的显著提升）。 🔮 未来趋势 - MCP 协议与 LLM 能力会持续演进。 - 工具设计将从“确定性 API”转向“面向 Agent 的非确定性接口”。 - 评估驱动的迭代将成为构建 Agent 工具生态的核心流程。

Week 4  Agent Autonomy Levels（0-5 级，从工具调用到完全自治）。  Human-in-the-Loop 协作：Claude Code 的 Slash Commands、CLAUDE.md 仓库级指导、Sub-Agents。  Multi-Agent 编排。 New-Item -ItemType SymbolicLink -Path "$env:USERPROFILE\.config\opencode\plugins\superpowers.js" -Target "$env:USERPROFILE.config\opencode\superpowers.opencode\plugins\superpowers.js"

表格 1¶

角色	职责
AI Champion（1–2 人）	维护 AGENTS.md、优化 AI 环境、制定规范
工程师	使用 AI 完成日常任务、提交反馈
Tech Lead	评估 AI 生成代码质量、推动工作流集成
QA	使用 AI 自动生成测试、补齐覆盖率

表格 2¶

阶段	特征
Level 1：试用	工程师偶尔使用 AI
Level 2：任务级使用	AI 参与部分开发任务
Level 3：工作流集成	Ask → Code、AI PR、AI backlog
Level 4：体系化	AGENTS.md、Best-of-N、团队规范
Level 5：AI-native	50%+ 代码由 AI 生成，工程师专注架构与决策