[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"projects":3},[4,42,76,107,134,160,185],{"id":5,"slug":6,"name":7,"summary":8,"stack":9,"background":17,"responsibility":18,"workflow":19,"architecture":28,"highlights":29,"retrospective":38,"repositoryUrl":39,"liveUrl":40,"featured":41},3,"data-flow-rights-confirmation","数据流转确权平台","面向数据申请、审核、签名、确权和仲裁流程的 B 端平台，完成前端页面、接口联调与安全交互落地。",[10,11,12,13,14,15,16],"Vue 3","Vite","Pinia","Element Plus","Spring Boot","Oracle","JWT \u002F ECDH","平台解决的是数据使用权怎么申请、怎么审批、怎么签名、怎么最终确权，以及异常流程怎么进入仲裁。\n\n它不是一个普通后台，而是一个多角色、多状态、强约束的业务系统。前端页面必须把任务申请、审核、签名、确权和仲裁状态转成清晰的操作反馈。\n\n项目源码使用 Spring Boot 2.5.6、Oracle、MyBatis-Plus、JWT、ECDH 和请求签名。前端负责把后端能力组织成业务页面。","负责前端页面开发、接口联调和兼容性处理。\n\n- 完成签名生成、签名进度和最终确权页面\n- 完成授权方在线身份校验\n- 完成高风险操作二次确认\n- 整理任务申请、审核、签名、确权和仲裁状态\n- 处理登录态、请求签名、业务错误码和接口联调\n- 修复重复提交、状态不同步和兼容性问题",[20,21,22,23,24,25,26,27],"发起数据使用与签名申请","业务人员审核申请","审核通过后创建任务","参与方按顺序生成签名","授权方完成在线身份校验","相关方完成最终确权","异常结果进入仲裁","仲裁结果写回任务状态","前端使用 Vue 3、Vite、Pinia 和 Element Plus，通过 Axios 对接 Spring Boot 和 Oracle。\n\n后端按 Controller、Service、Mapper、Model 分层。认证使用 JWT，关键通信链路使用 ECDH 和请求签名，前端页面按业务状态拆分组件。\n\n签名、确认和高风险操作使用二次确认和提交中状态，避免重复提交。接口异常、登录态和业务错误码统一处理。",[30,31,32,33,34,35,36,37],"完成签名生成、签名进度和最终确权交互","完成授权方在线身份校验","高风险操作二次确认","统一任务申请、审核、签名、确权和仲裁反馈","处理不同浏览器兼容性","修复接口异常、状态不同步和重复提交","统一加载和错误组件","联调登录态、请求签名和业务错误码","流程型 B 端页面最重要的不是视觉复杂，而是角色、状态和操作顺序是否清楚。\n\n前端隐藏按钮只能减少误操作，真正权限校验必须由后端完成。联调时也要把登录态、请求签名和业务错误码放在同一套流程测试，否则单页正常，组合流程仍会出问题。","https:\u002F\u002Fgithub.com\u002FS1rryNut\u002Fdata-circulation-platform",null,true,{"id":43,"slug":44,"name":45,"summary":46,"stack":47,"background":54,"responsibility":55,"workflow":56,"architecture":64,"highlights":65,"retrospective":74,"repositoryUrl":75,"liveUrl":40,"featured":41},1,"distributed-certificate-storage","业务数据授权去中心化存证系统","面向联盟链业务数据授权与存证的前端系统，覆盖授权确认、链上存证和结果核验，并处理复杂业务状态和长列表性能。",[10,11,12,13,48,14,49,50,51,15,52,53],"Java","MyBatis-Plus","Redis","SQLite","JWT","SM2\u002FSM3","项目面向联盟链中的业务数据授权场景。用户完成数据授权后，系统需要把授权过程、存证结果和核验状态串成一条可追踪链路。\n\n前端重点不是展示后台 CRUD，而是让业务用户理解当前数据走到哪一步、参与者是否完成确认、异常应该从哪个环节处理。\n\n源码中同时存在 coordinator 与 node 两类 Spring Boot 服务，分别承担协调、证书管理和节点存证，前端通过接口与这些服务协作。","参与前端方案设计和主要页面开发。\n\n- 整理授权确认、链上存证和结果核验的状态流\n- 实现接口缓存、并发去重和按 Tag 失效\n- 处理长列表虚拟滚动\n- 记录 Web Vitals、路由耗时和接口耗时\n- 处理证书上传、地址校验和节点通信相关安全边界",[57,58,59,60,61,62,63],"用户发起业务数据授权","系统整理授权主体和数据范围","用户完成授权确认","授权结果进入链上存证","参与节点保存并返回处理状态","用户核验数据和签名结果","异常进入可追踪反馈流程","前端使用 Vue 3、Vite、Pinia 和 Element Plus。接口层封装 TTL 缓存、并发去重、SWR 和 Tag 失效，长列表通过虚拟滚动控制 DOM 数量。\n\n后端拆分为 coordinator 与 node 两类 Spring Boot 服务。coordinator 维护成员、证书和任务状态，node 处理签名、证书校验和数据保存。数据访问使用 MyBatis-Plus，coordinator 使用 Redis 和 Oracle，node 使用 SQLite。\n\n认证和签名链路包含 JWT、SM2\u002FSM3，节点通信使用 HTTP，并对远程地址、证书有效期、签发方和上传文件做校验。",[66,67,68,69,70,71,72,73],"请求缓存使用 TTL、并发去重、SWR 和 Tag 失效","列表使用虚拟滚动，减少长数据下的 DOM 压力","记录 LCP、INP、CLS、路由耗时和 API 耗时","授权、存证、核验和异常页面共用一致的状态反馈","证书上传限制扩展名并验证证书有效期","节点通信前校验远程地址，避免任意内网访问","写操作关联缓存 Tag，保证列表和详情同步刷新","接口异常保留用户输入，并展示可理解的原因","这个项目里，最难的不是页面数量，而是把多个服务返回的数据合并成一致状态。\n\n缓存和虚拟列表提升了性能，但如果状态反馈不一致，用户反而更难判断结果。后面再做业务系统，会更早定义状态机、异常路径和权限边界，不让前端用大量条件判断弥补后端状态不清晰。","https:\u002F\u002Fgithub.com\u002FS1rryNut\u002Fdistributed-certificate-storage",{"id":77,"slug":78,"name":79,"summary":80,"stack":81,"background":85,"responsibility":86,"workflow":87,"architecture":95,"highlights":96,"retrospective":105,"repositoryUrl":106,"liveUrl":40,"featured":41},2,"personal-content-ai-site","个人内容与 AI 学习站","个人数字空间，统一管理博客、项目案例、AI 学习、游戏档案、留言和内容后台，并完成部署、备份与安全加固。",[82,83,14,84],"Nuxt","Vue","PostgreSQL","这个网站把原来分散在本地笔记、项目目录和简历里的内容统一管理。\n\n公开页面包括文章、项目案例、AI 学习、游戏档案、Now 和留言，后台供个人维护。\n\n目标不是堆功能，而是让内容能长期维护：文章能编辑、草稿能保存、项目能补细节、游戏库能自动同步，同时控制部署和运维复杂度。","独立完成产品结构、数据库、前后端、部署和日常维护。\n\n- 设计文章、项目、AI、游戏和 Now 的数据结构\n- 开发 Nuxt 公开页面和 Vue 内容后台\n- 开发 Spring Boot API、认证和图片上传\n- 配置 PostgreSQL、Nginx、systemd 和定时任务\n- 处理备份、日志轮转、资源巡检和 HTTPS",[88,89,90,91,92,93,94],"后台创建或编辑内容","后端校验字段、权限和固定链接","Markdown 内容保存为文章","公开接口只返回已发布数据","Nuxt 在服务端渲染公开页面","Nginx 统一代理 API 和前端","定时任务维护备份、统计和游戏同步","前端采用 Nuxt 4 和 Vue 3，公开页面使用服务端渲染。后台是同一套 Nuxt 项目，通过受保护的 \u002Fadmin 路由提供内容管理。\n\n后端使用 Spring Boot 和 PostgreSQL。认证采用 Argon2id、会话 Cookie、CSRF、登录限流和 Bearer Token；文章正文使用 Markdown，图片上传后统一验证和压缩。\n\nNginx 负责 HTTPS、反向代理、安全响应头和静态资源缓存。服务由 systemd 管理，数据库和发布目录保留备份。",[97,98,99,100,101,102,103,104],"文章支持 Markdown、图片上传、草稿、历史版本和复制","后台支持项目、游戏档案、AI 学习、热点、账号和 Now","公开文章按技术、游戏和 AI 分类，URL 保持稳定","后台认证使用 Argon2id、HttpOnly Cookie、CSRF 和限流","Steam 使用 Web API 同步游戏库和最近两周游玩状态","留言使用 CSRF、字段校验和 IP 频率限制","数据库、前端发布和系统服务有备份与恢复策略","日志轮转、资源巡检和健康检查覆盖日常运维","个人项目最大的风险不是某个功能做不出来，而是内容越堆越难维护。\n\n这个站先保证文章、项目和游戏档案的数据结构清楚，再逐步增加自动化。后面会把更多重复维护交给定时任务，公开页面保持简单，后台提供更明确的状态和错误提示。","https:\u002F\u002Fgithub.com\u002FS1rryNut\u002Fco11ap5e",{"id":108,"slug":109,"name":110,"summary":111,"stack":112,"background":117,"responsibility":118,"workflow":119,"architecture":126,"highlights":127,"retrospective":132,"repositoryUrl":133,"liveUrl":40,"featured":41},5,"co11ap5e-agent","co11ap5e_agent（轻量 ReAct Agent 框架）","不依赖 LangChain 的轻量 ReAct Agent 框架，用原生 OpenAI SDK 从零构建，兼容 DeepSeek \u002F DashScope \u002F OpenAI。",[113,114,115,116],"Python","OpenAI SDK","Pydantic","ReAct","从零构建一个不依赖重型框架的 Agent 运行内核：只保留 openai \u002F pydantic \u002F httpx，用原生 SDK 实现 ReAct 主循环、工具调用与记忆管理，目标是让每一层都能逐行解释。","独立完成框架设计、实现与测试。\n\n- 实现 Thought → Action → Observation 的 ReAct 核心循环\n- 用 @tool 装饰器从函数签名自动生成 OpenAI Function Calling JSON Schema\n- 构建短期（摘要压缩）、工作（任务 scratchpad）、长期（JSON 持久化）三层记忆体系\n- 实现容错 JSON 解析与 Plan-and-Execute 规划器\n- 处理工具超时、连续失败与最大迭代保护",[120,121,122,123,124,125],"接收用户任务","规划器判断是否需要拆解子任务","进入 ReAct 循环：思考 → 调工具 → 观察结果","工具执行与参数容错解析","结果写入短期记忆并维护工作记忆","达到目标后输出最终回答","仅依赖 openai \u002F pydantic \u002F httpx，核心为自研 ReAct 循环；记忆分短期 \u002F 工作 \u002F 长期三层；工具系统基于函数签名自动生成 Schema；提供 astream_chat 流式输出。",[128,129,130,131],"零框架依赖，核心循环全自研","三层记忆体系按任务生命周期管理","容错解析 LLM 输出的不规范 JSON","支持 DeepSeek \u002F DashScope \u002F OpenAI 多后端","Agent 框架的价值不在于炫技，而在于把「思考-行动-观察」的主循环、记忆边界和错误恢复设计清楚。自研让每个行为都可解释，也方便面试时讲清设计取舍。","https:\u002F\u002Fgithub.com\u002FS1rryNut\u002Fco11ap5e_agent",{"id":135,"slug":136,"name":137,"summary":138,"stack":139,"background":143,"responsibility":144,"workflow":145,"architecture":152,"highlights":153,"retrospective":158,"repositoryUrl":159,"liveUrl":40,"featured":41},6,"co11ap5e-coding-agent","co11ap5e_coding_agent（TDD 编程助手）","基于自研 ReAct Agent 框架扩展的 AI 编程助手，内置强制 TDD 循环，自动完成写测试 → 跑测试（RED）→ 写实现 → 再跑测试（GREEN）的完整开发流程。",[113,140,141,142],"tiktoken","TDD","AST","在自研 ReAct 框架之上构建一个面向真实工程的 Coding Agent：用 Repo Map 理解代码库、用 tiktoken 精确计费并自动压缩上下文、用强制 TDD 循环保证产出经过测试验证。","独立完成架构设计与实现。\n\n- 实现 TDD 红绿循环：先写测试再写实现，全部通过才收尾\n- 用 AST 提取函数 \u002F 类 \u002F 导入符号，按重要性生成 token 预算内的 Repo Map\n- 基于 tiktoken 精确统计 token，超预算自动把旧消息压缩为摘要\n- 实现 9 个内置工具：文件读写改、Shell、代码搜索、Git 操作\n- 工具参数容错解析，执行错误回填给 LLM 自行修正",[146,147,148,149,150,151],"接收编程任务","扫描代码库生成 Repo Map","按 TDD 流程先写测试并运行（RED）","再写实现并运行（GREEN）","失败则读错误信息修正后重试","全部通过后输出总结","自研 ReAct 主循环 + TDD 纪律；AST Repo Map 提供代码库概览；tiktoken 精确 token 预算与自动摘要压缩；项目记忆持久化到 .coding_agent\u002Fproject_memory.json。",[154,155,156,157],"强制 TDD 循环，测试驱动开发","AST Repo Map 在预算内理解代码库","tiktoken 精确计数与自动压缩","9 个内置工具覆盖文件 \u002F Shell \u002F 搜索 \u002F Git","与主流 Coding Agent 对比，本项目定位教学 \u002F 学习级：每一层（ReAct、工具系统、记忆、TDD）都可逐行解释，透明可控是核心价值。","https:\u002F\u002Fgithub.com\u002FS1rryNut\u002Fco11ap5e_coding_agent",{"id":161,"slug":162,"name":163,"summary":164,"stack":165,"background":168,"responsibility":169,"workflow":170,"architecture":177,"highlights":178,"retrospective":183,"repositoryUrl":184,"liveUrl":40,"featured":41},7,"co11ap5e-multi-agent","co11ap5e_multi_agent（多 Agent 软件研发团队）","类 MetaGPT 的多 Agent 软件研发系统，PM \u002F 架构师 \u002F 程序员 \u002F 测试 \u002F PMO 五个角色协作完成需求 → PRD → 设计 → 编码 → 测试全流程，支持自动修 bug 与设计回退。",[113,166,167],"多智能体","角色编排","用多个专职角色 Agent 模拟软件研发团队：PM 写 PRD、架构师做设计、程序员编码、测试工程师验证，PMO 纯代码编排并控制回退，测试失败自动回退修 bug，多轮失败回退改设计。","独立完成系统设计与实现。\n\n- 设计 5 角色分工：PM \u002F Architect \u002F Coder \u002F Tester \u002F PMO\n- 实现测试失败自动回退 Coder 修 bug（最多 3 轮），超限回退 Architect 改设计\n- 用 WorkspaceContext 共享文件与状态，Agent 间不直接互调\n- 文件操作限制在 workspace 内，命令执行带超时保护\n- 按 assistant+tool 消息组整体截断记忆，避免半轮消息",[171,172,173,174,175,176],"接收用户需求","PM 分析需求并输出 PRD","Architect 输出技术设计","Coder 逐文件编码并自验证","Tester 写测试并运行","失败则回退 Coder \u002F Architect，通过则交付","基于自研 react_agent 框架，不依赖 LangChain \u002F AutoGen；PMO 纯代码编排；WorkspaceContext 共享上下文；工具沙箱限制文件操作范围。",[179,180,181,182],"5 角色协作覆盖研发全流程","自动回退：3 轮修 bug，超限改设计","共享上下文不直接互调，职责清晰","工具沙箱与超时保护","多智能体系统的难点不是让多个 Agent 说话，而是定义清晰的职责边界、共享状态和回退策略。PMO 用代码控制流程，比让 LLM 自由对话更可靠。","https:\u002F\u002Fgithub.com\u002FS1rryNut\u002Fco11ap5e_multi_agent",{"id":186,"slug":187,"name":188,"summary":189,"stack":190,"background":195,"responsibility":196,"workflow":197,"architecture":203,"highlights":204,"retrospective":209,"repositoryUrl":210,"liveUrl":40,"featured":41},8,"co11ap5e-enterprise-rag","co11ap5e_enterprise_rag（企业智能知识库平台）","基于 RAG 架构的企业知识库问答系统，支持多格式文档解析、向量检索、知识库管理与 LLM 生成带依据的回答，提供 REST API 接入。",[191,192,193,194],"FastAPI","Qdrant","DashScope","RAG","构建一个可落地的 RAG 知识库平台：文档上传解析 → 切片 → Embedding 向量化 → 语义检索 → 交给 LLM 生成带依据的回答，覆盖企业知识问答的完整链路。","独立完成后端架构与核心模块。\n\n- 支持 PDF \u002F Word \u002F PPT \u002F Excel 多格式文档解析\n- 基于 Embedding 向量化与 Qdrant 语义检索\n- 实现知识库生命周期管理与检索增强问答\n- 基于 FastAPI 提供 chat \u002F documents \u002F knowledge_base REST 接口",[198,199,200,201,202],"用户上传文档","解析文档并切片","Embedding 向量化存入 Qdrant","用户提问后检索相关片段","LLM 结合片段生成带依据的回答","FastAPI + Uvicorn 提供接口，Qdrant 做向量检索，DashScope 提供 LLM 与 Embedding，SQLAlchemy 管理元数据，PyMuPDF \u002F python-docx \u002F python-pptx \u002F openpyxl 负责多格式解析。",[205,206,207,208],"多格式办公文档解析","Qdrant 语义向量检索","知识库全生命周期管理","REST API 便于前端 \u002F 客户端接入","RAG 的价值在「检索的质量决定回答的质量」。把文档解析、切片、向量化、检索与生成串成清晰链路后，扩展新文档类型与新检索策略都变得可控。","https:\u002F\u002Fgithub.com\u002FS1rryNut\u002Fco11ap5e_enterprise_rag"]