很多人在学习大模型时会卡在一个很熟悉的问题上学了很多知识点但做不出完整项目开始做项目后又很快陷入边做边乱、需求飘移、笔记零散、复盘缺失的状态。 这不是因为不够努力而是因为缺了一套把“学习”和“项目实践”绑定在一起的工作方式。 files.eric.ed真正高效的做法不是把知识点、PRD、Spec、代码、实验记录分别管理而是把它们放进同一条链路中知识点用于解释项目PRD 用于定义目标Spec 用于约束行为代码和实验用于验证假设最后再把经验沉淀回知识库。 atlassian一、先建立一个正确的认知如果把“学习大模型”理解成看教程、记术语、做题那很容易进入一种虚假的熟练你知道 RAG、Agent、Tool Calling、Memory、Evaluation 这些词但并不知道它们为什么存在、在什么场景应该用、用了以后怎么判断有效。 项目式学习之所以更有效是因为它把知识放回真实问题中让学习围绕目标、约束、验证和反馈展开。 itali.uq.edu所以学习型项目最重要的不是“项目做得多复杂”而是“项目是否能持续逼你做四件事”定义问题、分解需求、实现能力、复盘认知。 这正好对应 PRD、Spec、代码和知识管理四个层面。 app.daily二、四层结构把学习和项目绑成一条链可以把整个练手项目拆成四层知识层、产品层、规格层、实现层。它们不是平行文档而是上下游关系。 files.eric.ed知识层我在学什么为什么学解决什么问题 ↓ 产品层PRD这个项目为什么存在要解决什么问题本阶段做什么 ↓ 规格层Spec系统必须怎么表现哪些场景成功哪些场景失败 ↓ 实现层代码、实验、评估、复盘 ↓ 反哺知识层我真正学会了什么哪里理解错了这套结构的价值在于它让你不再只是“学过”而是把每一个知识点都放进一个具体能力中去验证。 pblworks三、项目应该如何选练手项目不要一开始就追求“大而全”因为一旦范围太大你就会把时间消耗在搭框架和填坑上而不是学习关键能力。 更适合学习者的项目应该满足三个条件问题明确、能力聚焦、可阶段性交付。 ispring比较适合的大模型练手项目包括一个文档问答助手用来练 RAG、Chunking、引用返回和基础评估。一个 SQL/查询条件澄清助手用来练 Prompt、结构化输出、工作流拆分和失败兜底。一个工作流 Agent 原型用来练 Planner、Executor、Verifier 的编排。一个写作辅助工具用来练知识注入、风格控制和结果评估。项目不需要一开始就有前端或复杂工程化只要足够支撑“目标—需求—行为—验证”这条链就已经适合练习。 app.daily四、PRD 在学习项目中怎么写PRD 的作用不是把项目写得像正式商业立项书而是帮你在每个阶段都回答清楚我为什么做这个、这次要做到哪里、不做什么。 这对学习型项目尤其重要因为学习者最容易犯的错误就是范围不断膨胀。 perforce一个简化版 PRD 只需要包含下面几个部分背景为什么想做这个项目。目标想练什么能力想做成什么最小成果。用户谁会使用它哪怕当前只有你自己。核心能力这一阶段要实现的功能。Out of Scope这一阶段明确不做什么。成功标准如何判断这阶段练习有效。下面是一个简化例子# 项目文档问答助手 ## 背景 正在学习大模型希望通过一个小项目练习 RAG、提示词设计和回答评估。 ## 目标 做一个最小可用的问答助手能基于指定文档回答问题并返回引用片段。 ## 用户 当前用户是自己后续可给朋友试用。 ## 核心能力 - 上传或接入文档 - 检索相关片段 - 基于上下文回答 - 返回引用依据 ## 本阶段不做 - 多用户系统 - 权限控制 - 复杂前端 - 长期记忆 ## 成功标准 - 至少能正确回答 20 个测试问题中的 15 个 - 对于未知问题能明确说不知道 - 能解释每个模块为什么存在这个 PRD 已经足够支撑第一阶段开发而且能帮助你在练习中保持方向感。 atlassian五、Spec 在学习项目中怎么写如果说 PRD 解决的是“为什么做、做到哪里”那么 Spec 解决的就是“系统到底该怎么表现”。 这一步非常关键因为很多练手项目之所以做着做着没方向本质上是没有把“行为预期”写清楚。 linkedin一个最小可用的 Spec通常只要包含两类内容Requirement 和 Scenario。 intent-drivenRequirement系统应具备的能力。Scenario在具体条件下系统应如何表现。例如### Requirement: Answer Questions From Documents 系统 SHALL 基于已接入文档回答用户问题。 #### Scenario: Answer with relevant context Given 用户提出的问题在文档中有明确答案 When 系统完成检索并生成回答 Then 系统返回问题答案 And 返回相关引用片段 #### Scenario: Refuse when no supporting context exists Given 用户提出的问题在文档中没有足够依据 When 系统尝试检索文档 Then 系统返回无法确定答案的结果 And 不编造内容这类写法的价值在于它把“感觉对”变成了“可验证”。当你后续测试系统时可以直接拿 Scenario 来验收。 linkedin六、知识点应该怎么管理学习型项目里的知识管理重点不是记定义而是管理“知识点与项目能力之间的连接”。 也就是说知识点不能孤立存在它必须有自己的落点这个知识解决什么问题、对应项目哪个模块、你是否验证过它。 itali.uq.edu建议把知识笔记拆成四类1. 概念笔记记录一个概念的定义、用途、边界和相近概念差异。比如RAG、Function Calling、Reflection、Verifier、Prompt Routing。2. 模式笔记记录常见系统模式比如单 Agent、Plan-and-Execute、RAG Pipeline、Evaluator-Optimizer、Tool Use Workflow。重点不是“它是什么”而是“什么时候适合用”。3. 实验笔记记录你做了什么实验、为什么这么改、结果怎样、你对结果的解释是什么。实验笔记是学习项目最有价值的部分因为它能把“做过”变成“知道为什么这样做”。 files.eric.ed4. 错误笔记记录你哪里做错了、为什么错、下次如何避免。很多真正的进步都来自这类反思而不是来自成功案例。 ispring你可以用一张简单表格把知识和项目挂钩知识点解决的问题项目中的落点是否验证过RAG让模型基于私有知识回答检索层已做基础版本结构化输出让结果更稳定可消费输出层已验证 JSON 输出Evaluator判断回答是否靠谱验证层暂未实现Tool Calling扩展外部能力执行层待进入第二阶段这样你每学一个知识点都可以立刻判断它是现在该做还是以后再做。 ispring七、一个推荐的目录结构最实用的方式是把知识库、PRD、OpenSpec、代码和复盘放在同一个仓库中避免信息分散。 devmy-llm-project/ ├── README.md ├── docs/ │ ├── knowledge/ │ │ ├── concepts.md │ │ ├── patterns.md │ │ ├── experiments.md │ │ └── mistakes.md │ ├── prd/ │ │ └── v1-prd.md │ └── reviews/ │ └── weekly-review.md ├── openspec/ │ ├── AGENTS.md │ ├── project.md │ ├── specs/ │ └── changes/ ├── src/ └── tests/这套结构能让你在一个地方同时看到项目目标、项目约束、当前行为规范、实验记录和代码实现。 dev八、每周怎么推进才能真正练起来项目式学习最怕“想很多做很少”。所以最好把节奏固定成一周一个小循环每周只推动一个核心能力。 itali.uq.edu推荐的每周节奏如下第一步选一个本周主题例如第 1 周结构化输出第 2 周基础 RAG第 3 周评估机制第 4 周工作流拆分第二步写一页小 PRD只写本周目标、范围和成功标准控制在一页内。 perforce第三步写一个 OpenSpec change针对本周能力建立一个 change把 Requirement 和 2 到 5 个核心 Scenario 写清楚。 app.daily第四步实现最小版本只做能跑通主链路的最小能力不做提前优化。 ispring第五步做实验和验收至少准备 10 到 20 个例子来测试系统行为记录成功、失败和异常。 files.eric.ed第六步更新知识库把这周真正学到的内容写回知识笔记而不是只保留代码。 files.eric.ed第七步写复盘写三件事这周做成了什么、没做成什么、下周改什么。复盘比“继续努力”更重要因为它能让项目持续收敛。 northmead-h.schools.nsw.gov九、一个可以直接照做的实践模板如果希望明天就开始可以直接按下面这套方法执行。Day 1定项目题目选一个足够小的练手项目例如“文档问答助手”。项目题目越具体后续越容易收敛。 ispringDay 2写一页 PRD写清背景、目标、用户、核心能力、不做项和成功标准。 atlassianDay 3写第一版 Spec先写 2 个 Requirement每个 Requirement 写 2 个 Scenario不求全但一定要可验证。 app.dailyDay 4-5做最小实现先打通主链路例如文档切分、向量检索、生成回答、返回引用不要急着做前端和复杂工程。 ispringDay 6做测试集自己整理 10 到 20 个问题分成正确回答、无法回答、容易误答三类作为最初的评估集。 files.eric.edDay 7写复盘回答这四个问题本周项目往前推进了什么哪个知识点真正理解了哪个地方其实还没理解下周应该继续补哪个能力这一轮结束后再进入下一周的小迭代。 northmead-h.schools.nsw.gov十、你最终会得到什么如果持续用这种方式练 6 到 8 周你得到的不会只是一个 demo而是四类长期资产。 app.daily一个可以展示的项目原型。一套围绕项目沉淀下来的大模型知识库。一份逐步演进的 PRD 和 Spec 体系。一套你自己能够讲清楚的方法论。这也是项目式学习最重要的意义它不只让你“做出东西”更让你建立解释自己决策的能力而这恰恰是从“会用工具”走向“真正理解系统”的关键。 pblworks十一、最后的实践建议如果现在还不知道从哪里开始不要再继续收集方法直接从一个最小项目出发。先写一页 PRD再写两个 Requirement然后用一周时间把最小链路跑通。 你会很快发现真正带来成长的不是“学完再做”而是“在做的过程中逼自己把目标、行为、实现和理解逐层说清楚”。 atlassian对于学习大模型的人来说PRD 让项目不跑偏Spec 让系统可验证知识管理让成长可复用。把这三者绑在一起项目才不仅是练手也会变成你的方法论训练场。 atlassian
很多人在学习大模型时会卡在一个很熟悉的问题上学了很多知识点但做不出完整项目开始做项目后又很快陷入边做边乱、需求飘移、笔记零散、复盘缺失的状态。 这不是因为不够努力而是因为缺了一套把“学习”和“项目实践”绑定在一起的工作方式。 files.eric.ed真正高效的做法不是把知识点、PRD、Spec、代码、实验记录分别管理而是把它们放进同一条链路中知识点用于解释项目PRD 用于定义目标Spec 用于约束行为代码和实验用于验证假设最后再把经验沉淀回知识库。 atlassian一、先建立一个正确的认知如果把“学习大模型”理解成看教程、记术语、做题那很容易进入一种虚假的熟练你知道 RAG、Agent、Tool Calling、Memory、Evaluation 这些词但并不知道它们为什么存在、在什么场景应该用、用了以后怎么判断有效。 项目式学习之所以更有效是因为它把知识放回真实问题中让学习围绕目标、约束、验证和反馈展开。 itali.uq.edu所以学习型项目最重要的不是“项目做得多复杂”而是“项目是否能持续逼你做四件事”定义问题、分解需求、实现能力、复盘认知。 这正好对应 PRD、Spec、代码和知识管理四个层面。 app.daily二、四层结构把学习和项目绑成一条链可以把整个练手项目拆成四层知识层、产品层、规格层、实现层。它们不是平行文档而是上下游关系。 files.eric.ed知识层我在学什么为什么学解决什么问题 ↓ 产品层PRD这个项目为什么存在要解决什么问题本阶段做什么 ↓ 规格层Spec系统必须怎么表现哪些场景成功哪些场景失败 ↓ 实现层代码、实验、评估、复盘 ↓ 反哺知识层我真正学会了什么哪里理解错了这套结构的价值在于它让你不再只是“学过”而是把每一个知识点都放进一个具体能力中去验证。 pblworks三、项目应该如何选练手项目不要一开始就追求“大而全”因为一旦范围太大你就会把时间消耗在搭框架和填坑上而不是学习关键能力。 更适合学习者的项目应该满足三个条件问题明确、能力聚焦、可阶段性交付。 ispring比较适合的大模型练手项目包括一个文档问答助手用来练 RAG、Chunking、引用返回和基础评估。一个 SQL/查询条件澄清助手用来练 Prompt、结构化输出、工作流拆分和失败兜底。一个工作流 Agent 原型用来练 Planner、Executor、Verifier 的编排。一个写作辅助工具用来练知识注入、风格控制和结果评估。项目不需要一开始就有前端或复杂工程化只要足够支撑“目标—需求—行为—验证”这条链就已经适合练习。 app.daily四、PRD 在学习项目中怎么写PRD 的作用不是把项目写得像正式商业立项书而是帮你在每个阶段都回答清楚我为什么做这个、这次要做到哪里、不做什么。 这对学习型项目尤其重要因为学习者最容易犯的错误就是范围不断膨胀。 perforce一个简化版 PRD 只需要包含下面几个部分背景为什么想做这个项目。目标想练什么能力想做成什么最小成果。用户谁会使用它哪怕当前只有你自己。核心能力这一阶段要实现的功能。Out of Scope这一阶段明确不做什么。成功标准如何判断这阶段练习有效。下面是一个简化例子# 项目文档问答助手 ## 背景 正在学习大模型希望通过一个小项目练习 RAG、提示词设计和回答评估。 ## 目标 做一个最小可用的问答助手能基于指定文档回答问题并返回引用片段。 ## 用户 当前用户是自己后续可给朋友试用。 ## 核心能力 - 上传或接入文档 - 检索相关片段 - 基于上下文回答 - 返回引用依据 ## 本阶段不做 - 多用户系统 - 权限控制 - 复杂前端 - 长期记忆 ## 成功标准 - 至少能正确回答 20 个测试问题中的 15 个 - 对于未知问题能明确说不知道 - 能解释每个模块为什么存在这个 PRD 已经足够支撑第一阶段开发而且能帮助你在练习中保持方向感。 atlassian五、Spec 在学习项目中怎么写如果说 PRD 解决的是“为什么做、做到哪里”那么 Spec 解决的就是“系统到底该怎么表现”。 这一步非常关键因为很多练手项目之所以做着做着没方向本质上是没有把“行为预期”写清楚。 linkedin一个最小可用的 Spec通常只要包含两类内容Requirement 和 Scenario。 intent-drivenRequirement系统应具备的能力。Scenario在具体条件下系统应如何表现。例如### Requirement: Answer Questions From Documents 系统 SHALL 基于已接入文档回答用户问题。 #### Scenario: Answer with relevant context Given 用户提出的问题在文档中有明确答案 When 系统完成检索并生成回答 Then 系统返回问题答案 And 返回相关引用片段 #### Scenario: Refuse when no supporting context exists Given 用户提出的问题在文档中没有足够依据 When 系统尝试检索文档 Then 系统返回无法确定答案的结果 And 不编造内容这类写法的价值在于它把“感觉对”变成了“可验证”。当你后续测试系统时可以直接拿 Scenario 来验收。 linkedin六、知识点应该怎么管理学习型项目里的知识管理重点不是记定义而是管理“知识点与项目能力之间的连接”。 也就是说知识点不能孤立存在它必须有自己的落点这个知识解决什么问题、对应项目哪个模块、你是否验证过它。 itali.uq.edu建议把知识笔记拆成四类1. 概念笔记记录一个概念的定义、用途、边界和相近概念差异。比如RAG、Function Calling、Reflection、Verifier、Prompt Routing。2. 模式笔记记录常见系统模式比如单 Agent、Plan-and-Execute、RAG Pipeline、Evaluator-Optimizer、Tool Use Workflow。重点不是“它是什么”而是“什么时候适合用”。3. 实验笔记记录你做了什么实验、为什么这么改、结果怎样、你对结果的解释是什么。实验笔记是学习项目最有价值的部分因为它能把“做过”变成“知道为什么这样做”。 files.eric.ed4. 错误笔记记录你哪里做错了、为什么错、下次如何避免。很多真正的进步都来自这类反思而不是来自成功案例。 ispring你可以用一张简单表格把知识和项目挂钩知识点解决的问题项目中的落点是否验证过RAG让模型基于私有知识回答检索层已做基础版本结构化输出让结果更稳定可消费输出层已验证 JSON 输出Evaluator判断回答是否靠谱验证层暂未实现Tool Calling扩展外部能力执行层待进入第二阶段这样你每学一个知识点都可以立刻判断它是现在该做还是以后再做。 ispring七、一个推荐的目录结构最实用的方式是把知识库、PRD、OpenSpec、代码和复盘放在同一个仓库中避免信息分散。 devmy-llm-project/ ├── README.md ├── docs/ │ ├── knowledge/ │ │ ├── concepts.md │ │ ├── patterns.md │ │ ├── experiments.md │ │ └── mistakes.md │ ├── prd/ │ │ └── v1-prd.md │ └── reviews/ │ └── weekly-review.md ├── openspec/ │ ├── AGENTS.md │ ├── project.md │ ├── specs/ │ └── changes/ ├── src/ └── tests/这套结构能让你在一个地方同时看到项目目标、项目约束、当前行为规范、实验记录和代码实现。 dev八、每周怎么推进才能真正练起来项目式学习最怕“想很多做很少”。所以最好把节奏固定成一周一个小循环每周只推动一个核心能力。 itali.uq.edu推荐的每周节奏如下第一步选一个本周主题例如第 1 周结构化输出第 2 周基础 RAG第 3 周评估机制第 4 周工作流拆分第二步写一页小 PRD只写本周目标、范围和成功标准控制在一页内。 perforce第三步写一个 OpenSpec change针对本周能力建立一个 change把 Requirement 和 2 到 5 个核心 Scenario 写清楚。 app.daily第四步实现最小版本只做能跑通主链路的最小能力不做提前优化。 ispring第五步做实验和验收至少准备 10 到 20 个例子来测试系统行为记录成功、失败和异常。 files.eric.ed第六步更新知识库把这周真正学到的内容写回知识笔记而不是只保留代码。 files.eric.ed第七步写复盘写三件事这周做成了什么、没做成什么、下周改什么。复盘比“继续努力”更重要因为它能让项目持续收敛。 northmead-h.schools.nsw.gov九、一个可以直接照做的实践模板如果希望明天就开始可以直接按下面这套方法执行。Day 1定项目题目选一个足够小的练手项目例如“文档问答助手”。项目题目越具体后续越容易收敛。 ispringDay 2写一页 PRD写清背景、目标、用户、核心能力、不做项和成功标准。 atlassianDay 3写第一版 Spec先写 2 个 Requirement每个 Requirement 写 2 个 Scenario不求全但一定要可验证。 app.dailyDay 4-5做最小实现先打通主链路例如文档切分、向量检索、生成回答、返回引用不要急着做前端和复杂工程。 ispringDay 6做测试集自己整理 10 到 20 个问题分成正确回答、无法回答、容易误答三类作为最初的评估集。 files.eric.edDay 7写复盘回答这四个问题本周项目往前推进了什么哪个知识点真正理解了哪个地方其实还没理解下周应该继续补哪个能力这一轮结束后再进入下一周的小迭代。 northmead-h.schools.nsw.gov十、你最终会得到什么如果持续用这种方式练 6 到 8 周你得到的不会只是一个 demo而是四类长期资产。 app.daily一个可以展示的项目原型。一套围绕项目沉淀下来的大模型知识库。一份逐步演进的 PRD 和 Spec 体系。一套你自己能够讲清楚的方法论。这也是项目式学习最重要的意义它不只让你“做出东西”更让你建立解释自己决策的能力而这恰恰是从“会用工具”走向“真正理解系统”的关键。 pblworks十一、最后的实践建议如果现在还不知道从哪里开始不要再继续收集方法直接从一个最小项目出发。先写一页 PRD再写两个 Requirement然后用一周时间把最小链路跑通。 你会很快发现真正带来成长的不是“学完再做”而是“在做的过程中逼自己把目标、行为、实现和理解逐层说清楚”。 atlassian对于学习大模型的人来说PRD 让项目不跑偏Spec 让系统可验证知识管理让成长可复用。把这三者绑在一起项目才不仅是练手也会变成你的方法论训练场。 atlassian
