[{"data":1,"prerenderedAt":214},["ShallowReactive",2],{"$f9DbrePXPYDFgc1ZTcnWxkfpzm6Jl_1geKXop5T3BzWQ":3,"$ftpPqq6PbLvEXBqG56sssIPbIV6TEKKB04jkPvra41ho":201},{"items":4,"total":198,"page":199,"pageSize":200,"pageCount":199},[5,21,34,44,55,66,77,88,98,109,120,131,142,154,165,176,187],{"id":6,"slug":7,"title":8,"excerpt":9,"contentHtml":10,"coverImage":11,"status":12,"publishedAt":13,"updatedAt":13,"authorName":14,"categoryId":15,"tagIds":16,"seoTitle":19,"seoDescription":20},"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","cat-engineering",[17,18],"tag-nuxt","tag-vue","Nuxt SSR Blog 架构设计","一套使用 Nuxt SSR、Vue Admin 和 Tailwind 的 Blog 前端架构。",{"id":22,"slug":23,"title":24,"excerpt":25,"contentHtml":26,"coverImage":27,"status":12,"publishedAt":28,"updatedAt":28,"authorName":14,"categoryId":29,"tagIds":30,"seoTitle":33,"seoDescription":33},"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","cat-product",[31,32],"tag-design","tag-ops","",{"id":35,"slug":36,"title":37,"excerpt":38,"contentHtml":39,"coverImage":27,"status":12,"publishedAt":40,"updatedAt":40,"authorName":14,"categoryId":29,"tagIds":41,"seoTitle":42,"seoDescription":43},"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",[31],"产品空状态设计笔记","从说明、行动和反馈三个角度整理产品空状态的设计方法。",{"id":45,"slug":46,"title":47,"excerpt":48,"contentHtml":49,"coverImage":50,"status":12,"publishedAt":51,"updatedAt":51,"authorName":14,"categoryId":29,"tagIds":52,"seoTitle":53,"seoDescription":54},"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",[31,32],"反馈入口与产品运营闭环","围绕反馈入口、后台状态和内容迭代设计一个可运营的产品闭环。",{"id":56,"slug":57,"title":58,"excerpt":59,"contentHtml":60,"coverImage":61,"status":12,"publishedAt":62,"updatedAt":62,"authorName":14,"categoryId":29,"tagIds":63,"seoTitle":64,"seoDescription":65},"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",[31],"权限提示文案设计","把权限限制写成用户能理解、能行动的产品文案。",{"id":67,"slug":68,"title":69,"excerpt":70,"contentHtml":71,"coverImage":72,"status":12,"publishedAt":73,"updatedAt":73,"authorName":14,"categoryId":29,"tagIds":74,"seoTitle":75,"seoDescription":76},"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",[31,32],"后台列表页筛选设计","为什么后台产品早期应该优先打磨列表搜索、筛选和状态展示。",{"id":78,"slug":79,"title":80,"excerpt":81,"contentHtml":82,"coverImage":83,"status":12,"publishedAt":84,"updatedAt":84,"authorName":14,"categoryId":29,"tagIds":85,"seoTitle":86,"seoDescription":87},"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",[31,32],"内容发布流程的可逆设计","把草稿、发布和取消发布整理成清晰、可恢复的内容状态机。",{"id":89,"slug":90,"title":91,"excerpt":92,"contentHtml":93,"coverImage":11,"status":12,"publishedAt":94,"updatedAt":94,"authorName":14,"categoryId":15,"tagIds":95,"seoTitle":96,"seoDescription":97},"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",[18,32],"SSR 数据获取边界实践","整理公开页面服务端数据、SEO 内容和客户端交互之间的边界。",{"id":99,"slug":100,"title":101,"excerpt":102,"contentHtml":103,"coverImage":104,"status":12,"publishedAt":105,"updatedAt":105,"authorName":14,"categoryId":15,"tagIds":106,"seoTitle":107,"seoDescription":108},"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",[32],"前端 Mock API 状态隔离","让管理端和公开站点共享 Mock 状态，提前验证内容发布链路。",{"id":110,"slug":111,"title":112,"excerpt":113,"contentHtml":114,"coverImage":115,"status":12,"publishedAt":116,"updatedAt":116,"authorName":14,"categoryId":15,"tagIds":117,"seoTitle":118,"seoDescription":119},"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",[18,31],"Tailwind token 共享包实践","把颜色变量、暗色模式和基础 UI 样式抽到共享包的工程实践。",{"id":121,"slug":122,"title":123,"excerpt":124,"contentHtml":125,"coverImage":126,"status":12,"publishedAt":127,"updatedAt":127,"authorName":14,"categoryId":15,"tagIds":128,"seoTitle":129,"seoDescription":130},"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",[18,32],"富文本 HTML 清洗策略","针对后台富文本编辑器输出内容的保存前清洗和渲染策略。",{"id":132,"slug":133,"title":134,"excerpt":135,"contentHtml":136,"coverImage":137,"status":12,"publishedAt":138,"updatedAt":138,"authorName":14,"categoryId":15,"tagIds":139,"seoTitle":140,"seoDescription":141},"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",[18,32],"管理端路由守卫最小实现","用占位 token 完成后台入口保护，并为真实权限系统预留接入点。",{"id":143,"slug":144,"title":145,"excerpt":146,"contentHtml":147,"coverImage":148,"status":12,"publishedAt":149,"updatedAt":149,"authorName":14,"categoryId":150,"tagIds":151,"seoTitle":152,"seoDescription":153},"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","cat-field",[31,32],"样式迁移现场记录","记录一次从旧产物中对齐布局、卡片和表单样式的迁移过程。",{"id":155,"slug":156,"title":157,"excerpt":158,"contentHtml":159,"coverImage":160,"status":12,"publishedAt":161,"updatedAt":161,"authorName":14,"categoryId":150,"tagIds":162,"seoTitle":163,"seoDescription":164},"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",[31],"从截图还原 UI 状态","根据截图重建页面时需要补齐的交互状态和响应式细节。",{"id":166,"slug":167,"title":168,"excerpt":169,"contentHtml":170,"coverImage":171,"status":12,"publishedAt":172,"updatedAt":172,"authorName":14,"categoryId":150,"tagIds":173,"seoTitle":174,"seoDescription":175},"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",[32],"静态 HTML 兜底页面实践","直接打开访问的静态 HTML 页面如何处理数据、样式和链接。",{"id":177,"slug":178,"title":179,"excerpt":180,"contentHtml":181,"coverImage":182,"status":12,"publishedAt":183,"updatedAt":183,"authorName":14,"categoryId":150,"tagIds":184,"seoTitle":185,"seoDescription":186},"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",[32,31],"用 JSON 数据跑通内容审阅","在后端接入前，用 JSON 数据确认页面结构、字段命名和内容密度。",{"id":188,"slug":189,"title":190,"excerpt":191,"contentHtml":192,"coverImage":193,"status":12,"publishedAt":194,"updatedAt":194,"authorName":14,"categoryId":150,"tagIds":195,"seoTitle":196,"seoDescription":197},"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",[32],"发布记录与路线图复盘","把发布记录重新整理为路线图、用户承诺和优先级判断材料。",17,1,24,[202,206,210],{"id":29,"slug":203,"name":204,"description":205},"product","产品笔记","关于产品设计、用户体验和业务观察的长文。",{"id":15,"slug":207,"name":208,"description":209},"engineering","工程实践","前端、架构、性能和工程协作经验。",{"id":150,"slug":211,"name":212,"description":213},"field-notes","现场札记","真实项目中的决策记录和复盘。",1777827106930]