[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-docs-for-future-self-en":3,"blog-adjacent-docs-for-future-self-en":30,"blog-related-docs-for-future-self-en":65},{"id":4,"slug":5,"title":6,"excerpt":7,"content":8,"cover":9,"tone":10,"author":11,"publishedAt":12,"updatedAt":12,"readingMinutes":13,"featured":14,"tags":15,"category":19,"seoSettings":29},66,"docs-for-future-self","Write Product Docs for Your Future Self","Documentation is not a deliverable but team memory. Docs nobody reads are usually written for the wrong audience.","\u003Cp>At the end of a project the team is asked to produce documentation. What emerges is either a pile of screenshots or a user manual, and six months later nobody can explain why the design was chosen.\u003C\u002Fp>\n\u003Ch2>Three kinds, three readers\u003C\u002Fh2>\n\u003Cp>Decision records, written for the future team: why this approach and what was rejected.\u003C\u002Fp>\n\u003Cp>User guides, written for operators: clear steps, screenshots and common questions.\u003C\u002Fp>\n\u003Cp>API and data structure notes, written for developers: field meaning, allowed values and change history.\u003C\u002Fp>\n\u003Ch2>How to write docs that get read\u003C\u002Fh2>\n\u003Cp>One page per topic where possible. Long documents are rarely finished.\u003C\u002Fp>\n\u003Cp>Record date and author, so in three months people know whom to ask.\u003C\u002Fp>\n\u003Cp>Keep docs in the repository or project space, not on someone's laptop.\u003C\u002Fp>\n\u003Cp>The test is simple: can a newcomer keep the work moving using only the documentation?\u003C\u002Fp>","","indigo","佳益方圆团队","2026-04-06T09:28:00+08:00",1,false,[16,17,18],"Documentation","Team","Product",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":28,"count":21},2,0,"product-thinking","Product Thinking","Requirement analysis, user experience and product design methods, plus the thinking from business problems to product solutions.","lightbulb","blue","article",50,{},{"previous":31,"next":47},{"id":32,"slug":33,"title":34,"excerpt":35,"content":9,"cover":9,"tone":26,"author":11,"publishedAt":36,"updatedAt":36,"readingMinutes":13,"featured":14,"tags":37,"category":41},46,"api-rate-limiting","Rate Limiting: Protect the System Before Optimising Experience","Rate limits are not there to block users, but to keep most of the system available under abnormal traffic.","2026-04-08T09:28:00+08:00",[38,39,40],"APIs","Stability","Operations",{"id":13,"parentId":21,"slug":42,"name":43,"description":44,"icon":45,"cover":9,"tone":26,"kind":27,"sortOrder":46,"count":21},"engineering","Engineering","Hands-on engineering practices in architecture, performance optimization, AI integration and cross-platform delivery from our R and D team.","cpu",60,{"id":48,"slug":49,"title":50,"excerpt":51,"content":9,"cover":9,"tone":52,"author":11,"publishedAt":53,"updatedAt":53,"readingMinutes":13,"featured":14,"tags":54,"category":58},86,"peak-traffic-preparation","Retrospective: Scaling Up the Night Before the Sale","The campaign page was load-tested, but login and coupons were what fell over.","teal","2026-04-04T09:28:00+08:00",[55,56,57],"Retrospective","Peak Traffic","Performance",{"id":59,"parentId":21,"slug":60,"name":61,"description":62,"icon":63,"cover":9,"tone":26,"kind":27,"sortOrder":64,"count":21},3,"project-retrospective","Project Retrospectives","Real project records from zero to one, covering problems, solutions, lessons learned and final outcomes.","clipboard-check",40,[66,75,85],{"id":28,"slug":67,"title":68,"excerpt":69,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":70,"updatedAt":70,"readingMinutes":13,"featured":14,"tags":71,"category":74},"grading-requirement-confidence","Grading the Confidence Behind Requirements","Treating requirements as facts is the most common cause of delay. Requirements differ in how reliable they are.","2026-10-15T09:00:00+08:00",[72,18,73],"Requirements","Risk",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":28,"count":21},{"id":20,"slug":76,"title":77,"excerpt":78,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":79,"updatedAt":80,"readingMinutes":13,"featured":14,"tags":81,"category":84},"vertical-product-rules","The Watershed for Vertical Products: Writing Industry Defaults into the System","Vertical is not a new industry label on a generic product. The real barrier is understanding and carrying the default rules that practitioners take for granted.","2026-10-09T10:00:00+08:00","2026-10-18T15:58:14.661+08:00",[82,83],"Industry Products","Product Design",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":28,"count":21},{"id":86,"slug":87,"title":88,"excerpt":89,"content":9,"cover":9,"tone":26,"author":11,"publishedAt":90,"updatedAt":90,"readingMinutes":13,"featured":14,"tags":91,"category":93},51,"mvp-boundary","Drawing the Boundary of an MVP","Minimum viable is not the fewest features; it is one complete business loop running end to end.","2026-10-03T10:13:00+08:00",[92,18,72],"MVP",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":28,"count":21}]