[{"data":1,"prerenderedAt":227},["ShallowReactive",2],{"$f4NX5OeJGUutf9k30IppzO8G4sF4OBWYofmiOj1eJHMA":3,"$fAT8VJmsLnTsJ2znv3KCsSLV13pvRAqodWDre1Dz60lc":20,"$fuOIQyeMFu0-X_KmOrUnCUSR1Fx8DP_Q0yFmcYA6fMu8":36},[4,8,12,16],{"id":5,"slug":6,"name":7},"tag-vue","vue","Vue",{"id":9,"slug":10,"name":11},"tag-nuxt","nuxt","Nuxt",{"id":13,"slug":14,"name":15},"tag-design","design","Design",{"id":17,"slug":18,"name":19},"tag-ops","ops","Ops",[21,26,31],{"id":22,"slug":23,"name":24,"description":25},"cat-product","product","产品笔记","关于产品设计、用户体验和业务观察的长文。",{"id":27,"slug":28,"name":29,"description":30},"cat-engineering","engineering","工程实践","前端、架构、性能和工程协作经验。",{"id":32,"slug":33,"name":34,"description":35},"cat-field","field-notes","现场札记","真实项目中的决策记录和复盘。",{"items":37,"total":224,"page":225,"pageSize":226,"pageCount":225},[38,51,61,71,82,93,104,115,125,136,147,158,169,180,191,202,213],{"id":39,"slug":40,"title":41,"excerpt":42,"contentHtml":43,"coverImage":44,"status":45,"publishedAt":46,"updatedAt":46,"authorName":47,"categoryId":27,"tagIds":48,"seoTitle":49,"seoDescription":50},"post-1","nuxt-ssr-blog-architecture","用 Nuxt SSR 搭一个可运营的 Blog","从路由、数据获取、SEO 到后台编辑，整理一套轻量但完整的 Blog 前端架构。","\u003Ch2>为什么公开站点选择 SSR\u003C\u002Fh2>\u003Cp>Blog 的核心目标是被阅读、被索引、被分享。SSR 可以让文章标题、摘要和正文在首屏 HTML 中直接出现，也让搜索引擎和社交卡片获取稳定内容。\u003C\u002Fp>\u003Cp>后台依旧使用 Vite SPA，把高频操作保持在一个响应迅速的管理界面里。\u003C\u002Fp>\u003Cblockquote>\u003Cp>公开端追求可发现性，管理端追求操作效率。\u003C\u002Fp>\u003C\u002Fblockquote>\u003Ccode>npm list -g --depth-0\u003Cbr>npm i -g @anthropic-ai\u002Fclaude-code@latest\u003Cbr>npm i -g @openai\u002Fcodex@latest\u003Cbr>npm i -g @google\u002Fgemini-cli@latest\u003C\u002Fcode>\u003Ch2>基础规则\u003C\u002Fh2>\u003Cp>如果你没有时间看更详细的论坛规定，建议也看一下论坛的基础规则\u003Cbr>以下为论坛基础规则，违反基础规则会受到扣除大量鸡腿、禁言或者禁止账号的惩罚\u003C\u002Fp>\u003Col>\u003Cli>禁止人身攻击，辱骂他人，恶意引战，提倡理性讨论\u003C\u002Fli>\u003Cli>禁止讨论政治、成人\u002F低俗、暴力等及其他引起不适的内容\u003C\u002Fli>\u003Cli>禁止灰产黑产内容，如DDOS\u002FCC攻击、赌博，社工、免流等\u003C\u002Fli>\u003Cli>坚持“谁主张，谁举证”的原则，禁止故意扭曲事实抹黑他人\u003C\u002Fli>\u003Cli>不鼓励灌水行为，详细规定参考下方『灌水行为规定细则』\u003C\u002Fli>\u003Cli>对于代理技术的讨论，禁止分享神秘链接，禁止发布教程贴，详细规则见下方『代理相关的讨论的规定细则』\u003C\u002Fli>\u003Cli>对管理裁决有异议的，可以参考下方『申诉细则』\u003C\u002Fli>\u003C\u002Fol>\u003Ch2>等级相关\u003C\u002Fh2>\u003Cul>\u003Cli>用户等级由鸡腿数目动态计算得到，鸡腿数目越高等级越高，最高为Lv6\u003C\u002Fli>\u003Cli>当鸡腿降低至临界值的时候用户等级会同时降低，最低等级为Lv0；\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>鸡腿相关\u003C\u002Fh2>\u003Cp>鸡腿是本论坛使用的通用积分单位，鸡腿的数目对于用户来说非常重要！因为用户的等级，发表查看帖子的权限，邀请好友，点赞与反对等行为都与鸡腿相关。\u003C\u002Fp>\u003Ch3>收获鸡腿的方法\u003C\u002Fh3>\u003Cul>\u003Cli>注册后自动获得一定数目的鸡腿，目前设定为90\u003C\u002Fli>\u003Cli>每天签到可以获得指数随机数值的鸡腿，平均数值为5鸡腿\u002F天\u003C\u002Fli>\u003Cli>每次发表帖子获得5鸡腿，每天上限20\u003C\u002Fli>\u003Cli>每次发表评论获得1鸡腿，每天上限20\u003C\u002Fli>\u003Cli>帖子或评论被别人加鸡腿后，会增加相应的数目\u003C\u002Fli>\u003Cli>反馈论坛bug，核实后赠送鸡腿20-50个\u003C\u002Fli>\u003Cli>对论坛建设或论坛规定提出宝贵意见，采纳后赠送10-50鸡腿\u003C\u002Fli>\u003Cli>帖子被选为推荐阅读，将收到10-50鸡腿，详细说明参考\u003C\u002Fli>\u003Cli>管理可以获得每天5鸡腿的津贴\u003C\u002Fli>\u003C\u002Ful>\u003Ch3>消耗鸡腿的行为\u003C\u002Fh3>\u003Cul>\u003Cli>给喜欢的帖子或者评论加鸡腿后，会消耗掉自身一个鸡腿（同时增加被加鸡腿的用户一个鸡腿）\u003C\u002Fli>\u003Cli>反对你不支持的帖子或者评论，会消耗掉自身一个鸡腿，同时扣除被反对者一个鸡腿\u003C\u002Fli>\u003Cli>违反论坛规定，将扣除一定的鸡腿，详细规定参考\u003C\u002Fli>\u003C\u002Ful>\u003Ch3>鸡腿数目为负数的限制\u003C\u002Fh3>\u003Cul>\u003Cli>无法发表新的帖子和评论，无法回复私信\u003C\u002Fli>\u003Cli>鸡腿为负数的时候等级已经跌落至0，无法查看有阅读权限限制的帖子\u003C\u002Fli>\u003C\u002Ful>","\u002Fimages\u002Fblog\u002Fcovers\u002Fengineering-desk.jpg","published","2026-05-01T10:30:00.000Z","Gono",[9,5],"Nuxt SSR Blog 架构设计","一套使用 Nuxt SSR、Vue Admin 和 Tailwind 的 Blog 前端架构。",{"id":52,"slug":53,"title":54,"excerpt":55,"contentHtml":56,"coverImage":57,"status":45,"publishedAt":58,"updatedAt":58,"authorName":47,"categoryId":22,"tagIds":59,"seoTitle":60,"seoDescription":60},"post-2","admin-writing-workflow","后台写作工作流应该轻一点","管理后台不是越重越好，文章编辑、发布状态和 SEO 字段才是第一版真正重要的能力。","\u003Ch2>先把写作链路跑通\u003C\u002Fh2>\u003Cp>第一版后台应该围绕文章列表、编辑、预览、发布和分类标签组织。媒体库和 SEO 字段只需要做到足够顺手，别让内容维护的人迷路。\u003C\u002Fp>\u003Cul>\u003Cli>草稿可以随时保存\u003C\u002Fli>\u003Cli>发布动作明确可逆\u003C\u002Fli>\u003Cli>SEO 字段有合理 fallback\u003C\u002Fli>\u003C\u002Ful>","\u002Fimages\u002Fblog\u002Fcovers\u002Fplanning-notes.jpg","2026-04-28T08:00:00.000Z",[13,17],"",{"id":62,"slug":63,"title":64,"excerpt":65,"contentHtml":66,"coverImage":57,"status":45,"publishedAt":67,"updatedAt":67,"authorName":47,"categoryId":22,"tagIds":68,"seoTitle":69,"seoDescription":70},"post-product-1","product-empty-state-as-onboarding","让空状态成为产品的第一句解释","空状态不只是占位，它应该告诉用户当前发生了什么、下一步能做什么，以及系统会如何反馈。","\u003Ch2>空状态是一种入口\u003C\u002Fh2>\u003Cp>很多产品会把空状态写成一句“暂无数据”，但这其实错过了最重要的解释时刻。用户第一次进入页面时，空状态应该交代对象、边界和下一步动作。\u003C\u002Fp>\u003Cp>好的空状态像一个轻量的新手引导：告诉用户为什么现在为空，也告诉用户填充它之后会得到什么。\u003C\u002Fp>\u003Cul>\u003Cli>说明当前页面管理什么\u003C\u002Fli>\u003Cli>给出一个明确的主操作\u003C\u002Fli>\u003Cli>把错误、权限和加载状态区分开\u003C\u002Fli>\u003C\u002Ful>","2026-04-27T09:10:00.000Z",[13],"产品空状态设计笔记","从说明、行动和反馈三个角度整理产品空状态的设计方法。",{"id":72,"slug":73,"title":74,"excerpt":75,"contentHtml":76,"coverImage":77,"status":45,"publishedAt":78,"updatedAt":78,"authorName":47,"categoryId":22,"tagIds":79,"seoTitle":80,"seoDescription":81},"post-product-2","product-feedback-loop-from-entry","从反馈入口设计内容运营闭环","反馈入口不是一个表单按钮，而是连接用户问题、后台处理和公开内容迭代的运营回路。","\u003Ch2>反馈入口要能被追踪\u003C\u002Fh2>\u003Cp>一个有效的反馈系统应该把问题来源、处理状态和结果沉淀串起来。入口越轻，后续分流越要清楚，否则后台只会积累一堆难以行动的文本。\u003C\u002Fp>\u003Cp>可以把反馈分成缺陷、建议、内容补充和账号问题，再让每类反馈进入不同的处理节奏。\u003C\u002Fp>\u003Cblockquote>\u003Cp>能被处理的反馈，才是产品真正听见的声音。\u003C\u002Fp>\u003C\u002Fblockquote>","\u002Fimages\u002Fblog\u002Fcovers\u002Fwriting-feedback.jpg","2026-04-26T09:10:00.000Z",[13,17],"反馈入口与产品运营闭环","围绕反馈入口、后台状态和内容迭代设计一个可运营的产品闭环。",{"id":83,"slug":84,"title":85,"excerpt":86,"contentHtml":87,"coverImage":88,"status":45,"publishedAt":89,"updatedAt":89,"authorName":47,"categoryId":22,"tagIds":90,"seoTitle":91,"seoDescription":92},"post-product-3","product-permission-copy-promises","把权限文案写成用户能懂的承诺","权限提示应该解释风险和边界，而不是把接口名、角色名和内部流程丢给用户。","\u003Ch2>权限文案不是错误翻译\u003C\u002Fh2>\u003Cp>当用户看到权限提示时，他们关心的是自己为什么不能做、谁可以做、怎样恢复操作。产品文案需要把系统限制翻译成用户能理解的承诺。\u003C\u002Fp>\u003Cp>相比“无权限访问资源”，更好的表达是“当前账号只能查看这封邮件，不能修改共享设置”。这类句子会减少猜测，也会减少支持沟通。\u003C\u002Fp>","\u002Fimages\u002Fblog\u002Fcovers\u002Fpermission-copy.jpg","2026-04-25T09:10:00.000Z",[13],"权限提示文案设计","把权限限制写成用户能理解、能行动的产品文案。",{"id":94,"slug":95,"title":96,"excerpt":97,"contentHtml":98,"coverImage":99,"status":45,"publishedAt":100,"updatedAt":100,"authorName":47,"categoryId":22,"tagIds":101,"seoTitle":102,"seoDescription":103},"post-product-4","product-list-filtering-before-kanban","列表页筛选为何比看板更重要","早期后台产品最需要的是快速定位对象，筛选、搜索和状态列通常比复杂看板更先产生价值。","\u003Ch2>列表页承担日常工作\u003C\u002Fh2>\u003Cp>看板适合表达流程，但列表页更适合高频查找、批量处理和状态核对。第一版后台如果资源有限，应该优先把列表页的搜索、筛选、排序和空状态做扎实。\u003C\u002Fp>\u003Cp>当用户每天都要进入同一个页面处理内容，能否三秒找到目标，比界面看起来是否完整更重要。\u003C\u002Fp>","\u002Fimages\u002Fblog\u002Fcovers\u002Flist-filtering.jpg","2026-04-24T09:10:00.000Z",[13,17],"后台列表页筛选设计","为什么后台产品早期应该优先打磨列表搜索、筛选和状态展示。",{"id":105,"slug":106,"title":107,"excerpt":108,"contentHtml":109,"coverImage":110,"status":45,"publishedAt":111,"updatedAt":111,"authorName":47,"categoryId":22,"tagIds":112,"seoTitle":113,"seoDescription":114},"post-product-5","product-reversible-publishing-flow","发布流程里的可逆设计","发布、取消发布和草稿保存要被设计成可恢复的状态机，而不是一次性的危险按钮。","\u003Ch2>发布动作需要回路\u003C\u002Fh2>\u003Cp>内容系统里最常见的紧张时刻，是用户点击发布之后才发现标题、配图或 SEO 字段还需要调整。可逆设计的目标，是让用户知道每一步都可以被检查和恢复。\u003C\u002Fp>\u003Cp>草稿保存、发布确认、取消发布和修改后再发布应该形成清楚的状态机。这样后台不会显得笨重，用户也不会害怕操作。\u003C\u002Fp>","\u002Fimages\u002Fblog\u002Fcovers\u002Fpublishing-flow.jpg","2026-04-23T09:10:00.000Z",[13,17],"内容发布流程的可逆设计","把草稿、发布和取消发布整理成清晰、可恢复的内容状态机。",{"id":116,"slug":117,"title":118,"excerpt":119,"contentHtml":120,"coverImage":44,"status":45,"publishedAt":121,"updatedAt":121,"authorName":47,"categoryId":27,"tagIds":122,"seoTitle":123,"seoDescription":124},"post-engineering-1","engineering-ssr-data-boundaries","SSR 页面里的数据获取边界","公开页面要把首屏内容、SEO 信息和可交互状态拆开处理，避免服务端数据和客户端状态互相纠缠。","\u003Ch2>先确定首屏必须有什么\u003C\u002Fh2>\u003Cp>服务端渲染的公开页面，最重要的是首屏 HTML 中必须包含标题、摘要、正文和必要的结构化信息。交互状态可以延后，但内容本体不能等浏览器执行脚本后才出现。\u003C\u002Fp>\u003Cp>数据获取边界越清楚，页面越容易维护：文章详情走服务端读取，用户偏好和局部交互留给客户端处理。\u003C\u002Fp>","2026-04-22T09:10:00.000Z",[5,17],"SSR 数据获取边界实践","整理公开页面服务端数据、SEO 内容和客户端交互之间的边界。",{"id":126,"slug":127,"title":128,"excerpt":129,"contentHtml":130,"coverImage":131,"status":45,"publishedAt":132,"updatedAt":132,"authorName":47,"categoryId":27,"tagIds":133,"seoTitle":134,"seoDescription":135},"post-engineering-2","engineering-mock-api-state-isolation","前端 Mock API 的状态隔离","Mock API 不只是返回假数据，还要让公开站点和管理端共享同一套状态，方便联调真实流程。","\u003Ch2>Mock 要模拟流程而不是接口名\u003C\u002Fh2>\u003Cp>当管理端创建并发布文章后，公开站点应该立刻能读到同一篇文章。这样的 Mock 才能帮助我们验证真实业务链路，而不只是让页面不报错。\u003C\u002Fp>\u003Cp>内存状态适合早期开发，但要把类型、输入输出和错误处理做成接近真实后端的形态，后续替换时才不会大拆。\u003C\u002Fp>","\u002Fimages\u002Fblog\u002Fcovers\u002Fmock-api-state.jpg","2026-04-21T09:10:00.000Z",[17],"前端 Mock API 状态隔离","让管理端和公开站点共享 Mock 状态，提前验证内容发布链路。",{"id":137,"slug":138,"title":139,"excerpt":140,"contentHtml":141,"coverImage":142,"status":45,"publishedAt":143,"updatedAt":143,"authorName":47,"categoryId":27,"tagIds":144,"seoTitle":145,"seoDescription":146},"post-engineering-3","engineering-tailwind-token-package","把 Tailwind token 抽到共享包","当后台和公开站点同时存在时，颜色、圆角、排版和正文样式应该从共享 UI 包统一输出。","\u003Ch2>视觉 token 要有唯一来源\u003C\u002Fh2>\u003Cp>多个前端应用共存时，如果每个应用各自维护颜色变量和基础样式，细节很快就会分叉。共享 UI 包的价值，是把 HSL 变量、暗色模式和正文排版收拢到一个入口。\u003C\u002Fp>\u003Cp>业务组件可以分开写，但基础按钮、徽标、卡片和正文渲染应该保持一致。\u003C\u002Fp>","\u002Fimages\u002Fblog\u002Fcovers\u002Ftailwind-token.jpg","2026-04-20T09:10:00.000Z",[5,13],"Tailwind token 共享包实践","把颜色变量、暗色模式和基础 UI 样式抽到共享包的工程实践。",{"id":148,"slug":149,"title":150,"excerpt":151,"contentHtml":152,"coverImage":153,"status":45,"publishedAt":154,"updatedAt":154,"authorName":47,"categoryId":27,"tagIds":155,"seoTitle":156,"seoDescription":157},"post-engineering-4","engineering-sanitize-rich-text-html","富文本保存前的 HTML 清洗策略","富文本编辑器输出的是 HTML，保存前必须明确允许哪些标签、属性和嵌入内容。","\u003Ch2>富文本不是可信输入\u003C\u002Fh2>\u003Cp>所见即所得编辑器会让内容维护变得顺手，但它输出的 HTML 仍然需要清洗。保存前清洗可以让数据库里的内容更可控，渲染端也不必承担过多安全压力。\u003C\u002Fp>\u003Cp>建议把清洗策略放在保存动作附近，并让预览和最终展示都走同一份内容。\u003C\u002Fp>","\u002Fimages\u002Fblog\u002Fcovers\u002Frich-text-sanitize.jpg","2026-04-19T09:10:00.000Z",[5,17],"富文本 HTML 清洗策略","针对后台富文本编辑器输出内容的保存前清洗和渲染策略。",{"id":159,"slug":160,"title":161,"excerpt":162,"contentHtml":163,"coverImage":164,"status":45,"publishedAt":165,"updatedAt":165,"authorName":47,"categoryId":27,"tagIds":166,"seoTitle":167,"seoDescription":168},"post-engineering-5","engineering-minimal-admin-route-guard","管理端路由守卫的最小实现","Mock 登录阶段不需要完整权限系统，但需要清楚地保护后台入口，并保留后续接入真实权限的位置。","\u003Ch2>先保护入口\u003C\u002Fh2>\u003Cp>早期管理端可以用一个占位 token 完成登录态判断。关键是把守卫位置、跳转逻辑和退出动作整理清楚，避免之后接入真实鉴权时到处找状态。\u003C\u002Fp>\u003Cp>最小实现不是随便实现，而是只实现当前阶段真正需要的边界。\u003C\u002Fp>","\u002Fimages\u002Fblog\u002Fcovers\u002Froute-guard.jpg","2026-04-18T09:10:00.000Z",[5,17],"管理端路由守卫最小实现","用占位 token 完成后台入口保护，并为真实权限系统预留接入点。",{"id":170,"slug":171,"title":172,"excerpt":173,"contentHtml":174,"coverImage":175,"status":45,"publishedAt":176,"updatedAt":176,"authorName":47,"categoryId":32,"tagIds":177,"seoTitle":178,"seoDescription":179},"post-field-1","field-style-alignment-migration","一次迁移中的样式对齐记录","从旧产物迁移页面时，最稳的办法是先找布局、卡片、表单和状态色的原始来源。","\u003Ch2>先找样式的出处\u003C\u002Fh2>\u003Cp>迁移页面最容易犯的错，是凭印象重写一套差不多的样式。更稳的做法是回到原始产物，找到布局容器、导航项、卡片和表单控件的类名，再逐步替换页面结构。\u003C\u002Fp>\u003Cp>这样做慢一点，但最终页面会更像同一个系统里长出来的。\u003C\u002Fp>","\u002Fimages\u002Fblog\u002Fcovers\u002Fstyle-alignment.jpg","2026-04-17T09:10:00.000Z",[13,17],"样式迁移现场记录","记录一次从旧产物中对齐布局、卡片和表单样式的迁移过程。",{"id":181,"slug":182,"title":183,"excerpt":184,"contentHtml":185,"coverImage":186,"status":45,"publishedAt":187,"updatedAt":187,"authorName":47,"categoryId":32,"tagIds":188,"seoTitle":189,"seoDescription":190},"post-field-2","field-recreate-ui-from-screenshot","从截图还原交互状态的办法","截图只能展示一个瞬间，真正还原界面时要补齐 hover、active、empty 和 disabled 状态。","\u003Ch2>截图之外还有状态\u003C\u002Fh2>\u003Cp>根据截图还原页面时，不能只盯着颜色和间距。一个真实可用的页面还需要处理当前选中、空数据、禁用按钮、移动端折行和长文本溢出。\u003C\u002Fp>\u003Cp>还原的目标不是制造一张静态图，而是让页面在常见数据下都保持稳定。\u003C\u002Fp>","\u002Fimages\u002Fblog\u002Fcovers\u002Fui-from-screenshot.jpg","2026-04-16T09:10:00.000Z",[13],"从截图还原 UI 状态","根据截图重建页面时需要补齐的交互状态和响应式细节。",{"id":192,"slug":193,"title":194,"excerpt":195,"contentHtml":196,"coverImage":197,"status":45,"publishedAt":198,"updatedAt":198,"authorName":47,"categoryId":32,"tagIds":199,"seoTitle":200,"seoDescription":201},"post-field-3","field-static-html-fallback-pages","静态 HTML 兜底页面的取舍","当页面需要直接打开访问时，数据、样式和链接都要在生成阶段固定下来。","\u003Ch2>直开页面要少依赖\u003C\u002Fh2>\u003Cp>静态 HTML 兜底页面最重要的要求，是不依赖运行时接口和应用加载脚本。所有能从数据文件得到的信息，都应该在生成阶段写进页面。\u003C\u002Fp>\u003Cp>这种方案不适合复杂交互，却非常适合交付快照、离线查看和审阅样式。\u003C\u002Fp>","\u002Fimages\u002Fblog\u002Fcovers\u002Fstatic-html-fallback.jpg","2026-04-15T09:10:00.000Z",[17],"静态 HTML 兜底页面实践","直接打开访问的静态 HTML 页面如何处理数据、样式和链接。",{"id":203,"slug":204,"title":205,"excerpt":206,"contentHtml":207,"coverImage":208,"status":45,"publishedAt":209,"updatedAt":209,"authorName":47,"categoryId":32,"tagIds":210,"seoTitle":211,"seoDescription":212},"post-field-4","field-json-first-content-review","用 JSON 先跑通内容审阅","在真实后端接入之前，JSON 数据能帮助团队先确认页面结构、字段命名和内容密度。","\u003Ch2>先用数据讨论页面\u003C\u002Fh2>\u003Cp>当接口还没稳定时，用 JSON 文件填充页面可以更早暴露信息架构问题。字段太少、卡片太密、标题太长，这些问题都能在静态数据阶段被看见。\u003C\u002Fp>\u003Cp>等真实后端接入时，团队已经对内容模型有了更具体的共识。\u003C\u002Fp>","\u002Fimages\u002Fblog\u002Fcovers\u002Fjson-content-review.jpg","2026-04-14T09:10:00.000Z",[17,13],"用 JSON 数据跑通内容审阅","在后端接入前，用 JSON 数据确认页面结构、字段命名和内容密度。",{"id":214,"slug":215,"title":216,"excerpt":217,"contentHtml":218,"coverImage":219,"status":45,"publishedAt":220,"updatedAt":220,"authorName":47,"categoryId":32,"tagIds":221,"seoTitle":222,"seoDescription":223},"post-field-5","field-release-note-to-roadmap","把发布记录整理成路线图材料","发布记录不只是更新日志，也可以反向整理出产品方向、用户承诺和下一阶段优先级。","\u003Ch2>发布记录里有路线图线索\u003C\u002Fh2>\u003Cp>一段时间的发布记录会暴露团队真正投入的方向。把它们按能力、体验、稳定性和运营工具重新分类，就能看出下一阶段路线图应该补哪里。\u003C\u002Fp>\u003Cp>现场复盘时，这类材料比抽象口号更有帮助，因为它来自已经发生过的工作。\u003C\u002Fp>","\u002Fimages\u002Fblog\u002Fcovers\u002Frelease-roadmap.jpg","2026-04-13T09:10:00.000Z",[17],"发布记录与路线图复盘","把发布记录重新整理为路线图、用户承诺和优先级判断材料。",17,1,100,1777827107313]