拓冰网站定制 
示例工程【免费下载链接】modern-software-dev-assignmentsAssignments for CS146S: The Modern Software Dev (Stanford University Fall 2026/2025)项目地址https://gitcode.com/GitHub_Trending/mo/modern-software-dev-assignments点击查看免费下载本文以 Stanford 课程 CS146S《现代软件开发》第一周作业week1/assignment.md为核心系统讲解 K-shot Prompting、Chain-of-Thought、Tool Calling、Self-Consistency、RAG 与 Reflexion 六种提示词技术的原理、源码实现与工程验证方式。读者完成本文后将能基于 Ollama 在本地运行开源大模型为每种技术设计可复现的提示词并通过自动化测试。作业概览为什么用提示词工程作为第一课该作业的目标很明确通过为 6 个具体任务手工构造提示词实践多种提示词技术。每个任务的指令位于对应源文件顶部学生需要找出代码中所有标记为TODO的位置——这是唯一需要改动的地方作业明确要求不要动模型本身即不改动模型选择、采样参数等。换句话说作业考查的是用提示词语言驱动模型行为的能力而非调参或微调能力。作业仓库位于项目根目录安装步骤见顶层 README.md完整作业描述见 week1/assignment.md。6 个技术文件全部位于 week1/ 目录下技术源文件K-shot prompting少样本提示week1/k_shot_prompting.pyChain-of-thought思维链week1/chain_of_thought.pyTool calling工具调用week1/tool_calling.pySelf-consistency prompting自洽性提示week1/self_consistency_prompting.pyRAG检索增强生成week1/rag.pyReflexion反思式自我改进week1/reflexion.py评分总计 60 分每种技术完成一个可用的 prompt 得 10 分6 种技术共 60 分。这意味着文章接下来分析的每个文件都直接对应 10 分。环境搭建从 Python 环境到本地大模型1. 仓库依赖安装Python 3.12 Poetry作业要求先完成顶层 README.md 中描述的安装。该步骤以 Python 3.12 为目标版本采用 Anaconda Poetry 的组合conda create -n cs146s python3.12 -y conda activate cs146s curl -sSL https://install.python-poetry.org | python - poetry install --no-interaction从 pyproject.toml 可以看到作业运行所需的 Python 依赖包括ollama ^0.5.3Ollama 官方 Python 客户端、python-dotenv加载环境变量、openai等开发依赖包括pytest、httpx、black、ruff与pre-commit。所有 6 个提示词脚本都通过from ollama import chat与本地模型对话。2. Ollama 安装与验证作业使用Ollama在本地运行多种当前主流开源 LLM按操作系统提供三种安装方式macOSHomebrewbrew install --cask ollama ollama serveLinux推荐curl -fsSL https://ollama.com/install.sh | shWindows从 ollama.com/download 下载并运行官方安装器。安装完成后验证版本ollama -v3. 拉取作业所需模型只需一次运行测试脚本前必须预先拉取两个模型除非日后手动删除否则只需拉取一次ollama run mistral-nemo:12b ollama run llama3.1:8b两个模型在 6 个任务中的分工是固定的只有 K-shot 任务使用mistral-nemo:12b其余 5 个任务全部使用llama3.1:8b。这一点可以直接从各源文件的chat(model...)调用中确认如 k_shot_prompting.py 与 chain_of_thought.py。六种提示词技术的源码级解读一、K-shot Prompting少样本示范引导输出格式K-shot少样本提示的核心思想是在提示中给出若干输入-输出示例让模型模仿示例的格式与推理方式。本任务的 k_shot_prompting.py 只要求反转单词httpstatus的字母顺序期望输出为sutatsptth。源码中的关键工程细节NUM_RUNS_TIMES 5 # 最多尝试 5 次任一成功即通过 YOUR_SYSTEM_PROMPT # TODO唯一需要填写的变量 USER_PROMPT Reverse the order of letters in the following word. Only output the reversed word, no other text: httpstatus EXPECTED_OUTPUT sutatsptth测试函数 test_your_prompt 以temperature0.5options{temperature: 0.5}对mistral-nemo:12b连续调用 5 次只要有一次输出与期望完全一致即打印SUCCESS并通过。由于模型具有随机性系统提示词必须做到两点给出正确的反转示范K-shot 的 K 就体现在这里并严格约束输出只包含反转结果避免模型附带解释或格式杂质。二、Chain-of-Thought让模型分步推理后再给答案思维链CoT通过要求模型先逐步推理再给出结论显著提升复杂数学与逻辑问题的成功率。chain_of_thought.py 的任务是计算3^{12345} (mod 100)期望输出为Answer: 43。该任务在工程实现上有两个值得注意的设计输出格式协议用户提示明确要求give the final answer on the last line as Answer: number这是为了配合后端的解析逻辑。正则解析器extract_final_answer 用re.findall(r(?mi)^\s*answer\s*:\s*(.)\s*$, text)找出最后一条以Answer:开头的行再从中提取数字并规范化为Answer: number。这意味着即使模型输出冗长的推理过程测试也只关心最后一行答案——这正是 CoT 提示推理过程随意、结论必须规范的典型工程形态。测试以temperature0.3调用llama3.1:8b最多 5 次只要解析后的最终答案等于Answer: 43即通过。实践要点系统提示词应引导模型先展示指数模运算的逐步化简如利用欧拉定理 φ(100)40 简化指数再用固定格式收尾。三、Tool Calling让模型学会调用工具而非直接作答工具调用函数调用是 Agent 能力的基石模型不直接给出答案而是输出一次对注册工具的调用请求由执行器解析并运行。tool_calling.py 构建了一个最小但完整的工具调用闭环工具注册表即执行器侧TOOL_REGISTRY: Dict[str, Callable[..., str]] { output_every_func_return_type: output_every_func_return_type, }output_every_func_return_type通过 Python 的ast模块静态解析目标文件返回每个顶层函数形如name: return_type的清单tool_calling.py脚本内还预置了add(a: int, b: int) - int与greet(name: str) - str两个样例函数供解析。模型侧协议模型必须输出一个 JSON 对象包含工具名与参数例如{tool: output_every_func_return_type, args: {file_path: tool_calling.py}}extract_tool_call 负责解析这段 JSON兼容被 代码围栏包裹的情况execute_tool_call 则查表调用对应函数并在参数中智能补全file_path默认值。测试流程test_your_prompt先计算真实结果作为基准再要求模型输出工具调用、执行之最后比对两者是否一致。注意此处NUM_RUNS_TIMES 3且temperature0.3。实践要点YOUR_SYSTEM_PROMPT必须向模型描述可用的工具名称、参数结构、JSON 输出格式以及每次只调用工具、不直接回答的行为约束——模型只有在系统提示词中看到工具说明时才会生成合法的调用 JSON。四、Self-Consistency Prompting多次采样 多数投票自洽性Self-Consistency提示是对 CoT 的强化用高温度多次独立采样再对答案做多数投票从而摊平单次推理的随机错误。self_consistency_prompting.py 的题目是一个简单的行程应用题Henry made two stops during his 60-mile bike trip. He first stopped after 20 miles. His second stop was 15 miles before the end of the trip. How many miles did he travel between his first and second stops?期望输出为Answer: 25第一次停在 20 英里处第二次停在 60−1545 英里处相距 25 英里。其核心投票逻辑在 test_your_prompt 中for idx in range(NUM_RUNS_TIMES): # NUM_RUNS_TIMES 5 response chat(modelllama3.1:8b, ..., options{temperature: 1}) final_answer extract_final_answer(output_text) answers.append(final_answer.strip()) counts Counter(answers) # 对 5 次采样结果计数 majority_answer, majority_count counts.most_common(1)[0]与 CoT 任务的关键差异是temperature1.0较高的采样温度放大输出的多样性使得投票才有意义随后Counter对 5 次Answer:行做多数表决多数答案命中Answer: 25即判定成功。调试时脚本还会打印答案分布便于观察模型是否在某类错误上系统性跑偏。五、RAG检索增强生成让模型只看该看的资料RAG 解决的是模型知识不足或过时的问题先检索出与问题相关的文档片段再拼接进提示词让模型只基于给定上下文作答。本任务rag.py让模型根据 API 文档编写一个调用GET /users/{id}接口的 Python 函数fetch_user_name(user_id, api_key) - str。知识库来源DATA_FILES指向 week1/data/api_docs.txt该文件以极简格式描述 APIBase URL: https://api.example.com/v1 Authentication: Provide header X-API-Key: your key Endpoints: GET /users/{id} - Returns 200 with JSON: {id: string, name: string}检索环节的 TODOYOUR_CONTEXT_PROVIDER(corpus)rag.py负责从语料库中挑选相关文档——默认返回[]模拟无上下文情形作业要求你改成把 API 文档注入上下文从而体会有检索 vs 无检索的显著差异。提示词拼接make_user_prompt 把检索结果包装成Context (use ONLY this information):块并硬性规定四项要求使用文档中的 Base URL 与端点、发送文档规定的认证头、对非 200 响应 raise、只返回用户名字符串。验证方式测试以temperature0.0完全确定性调用llama3.1:8b最多 5 次用必需片段匹配而非整串比对来评判代码正确性REQUIRED_SNIPPETS检查生成的代码是否包含REQUIRED_SNIPPETS [ def fetch_user_name(, requests.get, /users/, X-API-Key, return, ]这 5 个片段从函数签名、HTTP 调用、端点路径、认证头到返回值覆盖了 RAG 任务的核心验收点缺任一片段都会打印Missing required snippets并进入下一轮。六、Reflexion失败 → 反思 → 重写 的自我改进循环Reflexion 是具身智能体风格的自我改进范式模型先写代码用测试套件求值拿到失败诊断后再反思并重写。reflexion.py 的任务是生成一个is_valid_password(password: str) - bool函数密码需同时包含大写、小写、数字与特殊字符。真实测试套件作为求值基准reflexion.pySPECIALS set(!#$%^*()-_) TEST_CASES: List[Tuple[str, bool]] [ (Password1!, True), # valid (password1!, False), # missing uppercase (Password!, False), # missing digit (Password1, False), # missing special ]求值诊断器evaluate_function 对每个测试用例实际调用生成的函数若结果不符会基于真值规则生成可读诊断例如Failing checks: missing uppercase, missing digit——这些诊断字符串正是喂给反思环节的反思素材。反思环节的 TODOYOUR_REFLEXION_PROMPT与your_build_reflexion_context(prev_code, failures)reflexion.py是两个需要填写的关键点前者是反思系统提示词后者把上一版代码和失败诊断组装成用户消息。整个流程由 run_reflexion_flow 编排先用SYSTEM_PROMPT生成初始实现temperature0.2NUM_RUNS_TIMES1若测试全过直接成功否则执行单轮反思——把失败信息回传给模型要求其输出改进版代码再重新求值。由此可以直观看到带诊断的反思相比盲目重试的提升。交付物与评分标准作业对最终提交有明确要求week1/assignment.md阅读每个文件顶部的任务描述设计并运行提示词找出代码中所有TODO这是唯一允许改动的位置不要改动模型相关配置迭代改进提示词直至测试脚本通过脚本打印SUCCESS即通过为每种技术保存最终提示词与对应输出提交包含 6 个提示词技术文件完整代码的版本逐一确认所有TODO均已解决。评分规则共 60 分6 种提示词技术各 10 分每种技术只要提交了可用的 prompt 即可得分。小结一条完整的提示词工程方法论纵向看这 6 个任务其实勾勒出一条从单次提示到多轮自我改进的能力阶梯K-shot解决输出格式与风格模仿CoT解决复杂推理Tool Calling解决模型与外部工具/代码的对接Self-Consistency用采样投票解决单次推理的随机性RAG用检索注入解决知识时效与范围Reflexion用失败诊断驱动自我迭代。在每个任务中测试脚本都扮演了客观裁判的角色——它们要么比对精确字符串K-shot、CoT、Self-Consistency、要么校验 JSON 工具调用并比对真实结果Tool Calling、要么检查必需代码片段RAG、要么运行真实测试用例Reflexion。这种提示词设计 自动化验证的组合正是现代软件工程中评估与迭代 LLM 应用的标准姿势也是后续周次作业FastAPI 后端、测试与 CI 等的知识铺垫。赞分享示例工程【免费下载链接】modern-software-dev-assignmentsAssignments for CS146S: The Modern Software Dev (Stanford University Fall 2026/2025)项目地址https://gitcode.com/GitHub_Trending/mo/modern-software-dev-assignments点击查看免费下载相关推荐LLM Prompting Playground在 CS146S 项目中用 Ollama 实战六种核心 Prompting 技术LLM Prompting Playground在 CS146S 项目中用 Ollama 实战六种核心 Prompting 技术 CS146SStanfor示例工程提示工程基础实战指南基于 generative-ai-for-beginners 掌握 LLM 提示词的设计与优化提示工程基础实战指南基于 generative ai for beginners 掌握 LLM 提示词的设计与优化 本文是生成式 AI 入门课程genera教程人工智能大模型终极Prompt Engineering指南掌握AI提示词工程的核心策略与实战技巧终极Prompt Engineering指南掌握AI提示词工程的核心策略与实战技巧 Prompt Engineering是一种通过精心设计输入提示来引导AI模文档教程提示工程大模型人工智能RAGAI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CS146S 提示词技术实战：基于 Ollama 本地 LLM 掌握六种核心 Prompting 方法
示例工程【免费下载链接】modern-software-dev-assignmentsAssignments for CS146S: The Modern Software Dev (Stanford University Fall 2026/2025)项目地址https://gitcode.com/GitHub_Trending/mo/modern-software-dev-assignments点击查看免费下载本文以 Stanford 课程 CS146S《现代软件开发》第一周作业week1/assignment.md为核心系统讲解 K-shot Prompting、Chain-of-Thought、Tool Calling、Self-Consistency、RAG 与 Reflexion 六种提示词技术的原理、源码实现与工程验证方式。读者完成本文后将能基于 Ollama 在本地运行开源大模型为每种技术设计可复现的提示词并通过自动化测试。作业概览为什么用提示词工程作为第一课该作业的目标很明确通过为 6 个具体任务手工构造提示词实践多种提示词技术。每个任务的指令位于对应源文件顶部学生需要找出代码中所有标记为TODO的位置——这是唯一需要改动的地方作业明确要求不要动模型本身即不改动模型选择、采样参数等。换句话说作业考查的是用提示词语言驱动模型行为的能力而非调参或微调能力。作业仓库位于项目根目录安装步骤见顶层 README.md完整作业描述见 week1/assignment.md。6 个技术文件全部位于 week1/ 目录下技术源文件K-shot prompting少样本提示week1/k_shot_prompting.pyChain-of-thought思维链week1/chain_of_thought.pyTool calling工具调用week1/tool_calling.pySelf-consistency prompting自洽性提示week1/self_consistency_prompting.pyRAG检索增强生成week1/rag.pyReflexion反思式自我改进week1/reflexion.py评分总计 60 分每种技术完成一个可用的 prompt 得 10 分6 种技术共 60 分。这意味着文章接下来分析的每个文件都直接对应 10 分。环境搭建从 Python 环境到本地大模型1. 仓库依赖安装Python 3.12 Poetry作业要求先完成顶层 README.md 中描述的安装。该步骤以 Python 3.12 为目标版本采用 Anaconda Poetry 的组合conda create -n cs146s python3.12 -y conda activate cs146s curl -sSL https://install.python-poetry.org | python - poetry install --no-interaction从 pyproject.toml 可以看到作业运行所需的 Python 依赖包括ollama ^0.5.3Ollama 官方 Python 客户端、python-dotenv加载环境变量、openai等开发依赖包括pytest、httpx、black、ruff与pre-commit。所有 6 个提示词脚本都通过from ollama import chat与本地模型对话。2. Ollama 安装与验证作业使用Ollama在本地运行多种当前主流开源 LLM按操作系统提供三种安装方式macOSHomebrewbrew install --cask ollama ollama serveLinux推荐curl -fsSL https://ollama.com/install.sh | shWindows从 ollama.com/download 下载并运行官方安装器。安装完成后验证版本ollama -v3. 拉取作业所需模型只需一次运行测试脚本前必须预先拉取两个模型除非日后手动删除否则只需拉取一次ollama run mistral-nemo:12b ollama run llama3.1:8b两个模型在 6 个任务中的分工是固定的只有 K-shot 任务使用mistral-nemo:12b其余 5 个任务全部使用llama3.1:8b。这一点可以直接从各源文件的chat(model...)调用中确认如 k_shot_prompting.py 与 chain_of_thought.py。六种提示词技术的源码级解读一、K-shot Prompting少样本示范引导输出格式K-shot少样本提示的核心思想是在提示中给出若干输入-输出示例让模型模仿示例的格式与推理方式。本任务的 k_shot_prompting.py 只要求反转单词httpstatus的字母顺序期望输出为sutatsptth。源码中的关键工程细节NUM_RUNS_TIMES 5 # 最多尝试 5 次任一成功即通过 YOUR_SYSTEM_PROMPT # TODO唯一需要填写的变量 USER_PROMPT Reverse the order of letters in the following word. Only output the reversed word, no other text: httpstatus EXPECTED_OUTPUT sutatsptth测试函数 test_your_prompt 以temperature0.5options{temperature: 0.5}对mistral-nemo:12b连续调用 5 次只要有一次输出与期望完全一致即打印SUCCESS并通过。由于模型具有随机性系统提示词必须做到两点给出正确的反转示范K-shot 的 K 就体现在这里并严格约束输出只包含反转结果避免模型附带解释或格式杂质。二、Chain-of-Thought让模型分步推理后再给答案思维链CoT通过要求模型先逐步推理再给出结论显著提升复杂数学与逻辑问题的成功率。chain_of_thought.py 的任务是计算3^{12345} (mod 100)期望输出为Answer: 43。该任务在工程实现上有两个值得注意的设计输出格式协议用户提示明确要求give the final answer on the last line as Answer: number这是为了配合后端的解析逻辑。正则解析器extract_final_answer 用re.findall(r(?mi)^\s*answer\s*:\s*(.)\s*$, text)找出最后一条以Answer:开头的行再从中提取数字并规范化为Answer: number。这意味着即使模型输出冗长的推理过程测试也只关心最后一行答案——这正是 CoT 提示推理过程随意、结论必须规范的典型工程形态。测试以temperature0.3调用llama3.1:8b最多 5 次只要解析后的最终答案等于Answer: 43即通过。实践要点系统提示词应引导模型先展示指数模运算的逐步化简如利用欧拉定理 φ(100)40 简化指数再用固定格式收尾。三、Tool Calling让模型学会调用工具而非直接作答工具调用函数调用是 Agent 能力的基石模型不直接给出答案而是输出一次对注册工具的调用请求由执行器解析并运行。tool_calling.py 构建了一个最小但完整的工具调用闭环工具注册表即执行器侧TOOL_REGISTRY: Dict[str, Callable[..., str]] { output_every_func_return_type: output_every_func_return_type, }output_every_func_return_type通过 Python 的ast模块静态解析目标文件返回每个顶层函数形如name: return_type的清单tool_calling.py脚本内还预置了add(a: int, b: int) - int与greet(name: str) - str两个样例函数供解析。模型侧协议模型必须输出一个 JSON 对象包含工具名与参数例如{tool: output_every_func_return_type, args: {file_path: tool_calling.py}}extract_tool_call 负责解析这段 JSON兼容被 代码围栏包裹的情况execute_tool_call 则查表调用对应函数并在参数中智能补全file_path默认值。测试流程test_your_prompt先计算真实结果作为基准再要求模型输出工具调用、执行之最后比对两者是否一致。注意此处NUM_RUNS_TIMES 3且temperature0.3。实践要点YOUR_SYSTEM_PROMPT必须向模型描述可用的工具名称、参数结构、JSON 输出格式以及每次只调用工具、不直接回答的行为约束——模型只有在系统提示词中看到工具说明时才会生成合法的调用 JSON。四、Self-Consistency Prompting多次采样 多数投票自洽性Self-Consistency提示是对 CoT 的强化用高温度多次独立采样再对答案做多数投票从而摊平单次推理的随机错误。self_consistency_prompting.py 的题目是一个简单的行程应用题Henry made two stops during his 60-mile bike trip. He first stopped after 20 miles. His second stop was 15 miles before the end of the trip. How many miles did he travel between his first and second stops?期望输出为Answer: 25第一次停在 20 英里处第二次停在 60−1545 英里处相距 25 英里。其核心投票逻辑在 test_your_prompt 中for idx in range(NUM_RUNS_TIMES): # NUM_RUNS_TIMES 5 response chat(modelllama3.1:8b, ..., options{temperature: 1}) final_answer extract_final_answer(output_text) answers.append(final_answer.strip()) counts Counter(answers) # 对 5 次采样结果计数 majority_answer, majority_count counts.most_common(1)[0]与 CoT 任务的关键差异是temperature1.0较高的采样温度放大输出的多样性使得投票才有意义随后Counter对 5 次Answer:行做多数表决多数答案命中Answer: 25即判定成功。调试时脚本还会打印答案分布便于观察模型是否在某类错误上系统性跑偏。五、RAG检索增强生成让模型只看该看的资料RAG 解决的是模型知识不足或过时的问题先检索出与问题相关的文档片段再拼接进提示词让模型只基于给定上下文作答。本任务rag.py让模型根据 API 文档编写一个调用GET /users/{id}接口的 Python 函数fetch_user_name(user_id, api_key) - str。知识库来源DATA_FILES指向 week1/data/api_docs.txt该文件以极简格式描述 APIBase URL: https://api.example.com/v1 Authentication: Provide header X-API-Key: your key Endpoints: GET /users/{id} - Returns 200 with JSON: {id: string, name: string}检索环节的 TODOYOUR_CONTEXT_PROVIDER(corpus)rag.py负责从语料库中挑选相关文档——默认返回[]模拟无上下文情形作业要求你改成把 API 文档注入上下文从而体会有检索 vs 无检索的显著差异。提示词拼接make_user_prompt 把检索结果包装成Context (use ONLY this information):块并硬性规定四项要求使用文档中的 Base URL 与端点、发送文档规定的认证头、对非 200 响应 raise、只返回用户名字符串。验证方式测试以temperature0.0完全确定性调用llama3.1:8b最多 5 次用必需片段匹配而非整串比对来评判代码正确性REQUIRED_SNIPPETS检查生成的代码是否包含REQUIRED_SNIPPETS [ def fetch_user_name(, requests.get, /users/, X-API-Key, return, ]这 5 个片段从函数签名、HTTP 调用、端点路径、认证头到返回值覆盖了 RAG 任务的核心验收点缺任一片段都会打印Missing required snippets并进入下一轮。六、Reflexion失败 → 反思 → 重写 的自我改进循环Reflexion 是具身智能体风格的自我改进范式模型先写代码用测试套件求值拿到失败诊断后再反思并重写。reflexion.py 的任务是生成一个is_valid_password(password: str) - bool函数密码需同时包含大写、小写、数字与特殊字符。真实测试套件作为求值基准reflexion.pySPECIALS set(!#$%^*()-_) TEST_CASES: List[Tuple[str, bool]] [ (Password1!, True), # valid (password1!, False), # missing uppercase (Password!, False), # missing digit (Password1, False), # missing special ]求值诊断器evaluate_function 对每个测试用例实际调用生成的函数若结果不符会基于真值规则生成可读诊断例如Failing checks: missing uppercase, missing digit——这些诊断字符串正是喂给反思环节的反思素材。反思环节的 TODOYOUR_REFLEXION_PROMPT与your_build_reflexion_context(prev_code, failures)reflexion.py是两个需要填写的关键点前者是反思系统提示词后者把上一版代码和失败诊断组装成用户消息。整个流程由 run_reflexion_flow 编排先用SYSTEM_PROMPT生成初始实现temperature0.2NUM_RUNS_TIMES1若测试全过直接成功否则执行单轮反思——把失败信息回传给模型要求其输出改进版代码再重新求值。由此可以直观看到带诊断的反思相比盲目重试的提升。交付物与评分标准作业对最终提交有明确要求week1/assignment.md阅读每个文件顶部的任务描述设计并运行提示词找出代码中所有TODO这是唯一允许改动的位置不要改动模型相关配置迭代改进提示词直至测试脚本通过脚本打印SUCCESS即通过为每种技术保存最终提示词与对应输出提交包含 6 个提示词技术文件完整代码的版本逐一确认所有TODO均已解决。评分规则共 60 分6 种提示词技术各 10 分每种技术只要提交了可用的 prompt 即可得分。小结一条完整的提示词工程方法论纵向看这 6 个任务其实勾勒出一条从单次提示到多轮自我改进的能力阶梯K-shot解决输出格式与风格模仿CoT解决复杂推理Tool Calling解决模型与外部工具/代码的对接Self-Consistency用采样投票解决单次推理的随机性RAG用检索注入解决知识时效与范围Reflexion用失败诊断驱动自我迭代。在每个任务中测试脚本都扮演了客观裁判的角色——它们要么比对精确字符串K-shot、CoT、Self-Consistency、要么校验 JSON 工具调用并比对真实结果Tool Calling、要么检查必需代码片段RAG、要么运行真实测试用例Reflexion。这种提示词设计 自动化验证的组合正是现代软件工程中评估与迭代 LLM 应用的标准姿势也是后续周次作业FastAPI 后端、测试与 CI 等的知识铺垫。赞分享示例工程【免费下载链接】modern-software-dev-assignmentsAssignments for CS146S: The Modern Software Dev (Stanford University Fall 2026/2025)项目地址https://gitcode.com/GitHub_Trending/mo/modern-software-dev-assignments点击查看免费下载相关推荐LLM Prompting Playground在 CS146S 项目中用 Ollama 实战六种核心 Prompting 技术LLM Prompting Playground在 CS146S 项目中用 Ollama 实战六种核心 Prompting 技术 CS146SStanfor示例工程提示工程基础实战指南基于 generative-ai-for-beginners 掌握 LLM 提示词的设计与优化提示工程基础实战指南基于 generative ai for beginners 掌握 LLM 提示词的设计与优化 本文是生成式 AI 入门课程genera教程人工智能大模型终极Prompt Engineering指南掌握AI提示词工程的核心策略与实战技巧终极Prompt Engineering指南掌握AI提示词工程的核心策略与实战技巧 Prompt Engineering是一种通过精心设计输入提示来引导AI模文档教程提示工程大模型人工智能RAGAI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考