更新知识库文档：新增 agent、aitsc、claude code、组织架构等笔记
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
renjianbo
43
docs/Obsidian笔记体系/Projects/agent/wk3.md
Normal file
43
docs/Obsidian笔记体系/Projects/agent/wk3.md
Normal file
@@ -0,0 +1,43 @@
|
||||
会演进成一个 “可编排 + 可编程 + 可治理”的企业 Agent 平台，不是单纯聊天机器人，也不是完全黑盒自治体。你现在的基础已经在这条路上了。
|
||||
|
||||
## 你这套平台最可能的终局形态
|
||||
|
||||
- 上层：像“应用商店 + 主控台”
|
||||
- Main Agent 负责理解需求、路由到场景模板
|
||||
- 场景 Agent（客服/研发/运维/数据）可复用、可版本化
|
||||
- 中层：工作流与多 Agent 编排引擎
|
||||
- 现在的节点流（LLM/Loop/Cache）继续保留
|
||||
- 补上真实 `invoke_agent` / subworkflow 执行后，就能形成“主 Agent 调子 Agent”
|
||||
- 底层：工具与治理底座
|
||||
- 工具注册、权限隔离、审计日志、告警、预算控制、回滚策略
|
||||
|
||||
## 未来 3 个阶段（务实路线）
|
||||
|
||||
- 阶段1：稳态自动化（你已接近）
|
||||
|
||||
- 单 Agent 做稳定流程（客服、代码改造、日志分析）
|
||||
- 强化模板、提示词、失败重试与可观测性
|
||||
- 阶段2：多 Agent 协作
|
||||
|
||||
- Main Agent 做任务分解与分派
|
||||
- 子 Agent 并行执行，结果汇总
|
||||
- 关键节点加人工确认（Human-in-the-loop）
|
||||
- 阶段3：场景操作系统
|
||||
|
||||
- 模板市场（可复制、可参数化、可权限包）
|
||||
- 统一 DSL（输入约束、产物规范、验收标准）
|
||||
- 组织级治理：成本、合规、审计、SLA
|
||||
|
||||
## 和“推翻重写”相比的策略
|
||||
|
||||
- 不推翻：保留你当前最值钱的三件事
|
||||
- 可视化流程
|
||||
- 权限体系
|
||||
- 执行日志与审计
|
||||
- 渐进增强：补执行内核能力（真实子 Agent 调用）和产品层能力（模板化创建、主入口路由）。
|
||||
|
||||
---
|
||||
|
||||
一句话：
|
||||
它会从“工作流驱动的 Agent 平台”演进为“企业级场景自动化操作系统”——既有 OpenClaw 类的任务自治能力，又保留企业真正需要的可控和可审计。
|
||||
如果你愿意，我可以给你下一步的 90 天演进路线图（按你当前代码结构拆到文件级）。
|
||||
71
docs/Obsidian笔记体系/Projects/agent/wk4.md
Normal file
71
docs/Obsidian笔记体系/Projects/agent/wk4.md
Normal file
@@ -0,0 +1,71 @@
|
||||
项目分析总结
|
||||
|
||||
D:\aaa\aiagent 是一个低代码智能体平台，支持可视化工作流设计和智能Agent配置。
|
||||
|
||||
技术架构
|
||||
|
||||
- 前端: Vue 3 + TypeScript + Vite + Element Plus + Vue Flow（工作流可视化）
|
||||
- 后端: Python FastAPI + MySQL（腾讯云） + Redis + Celery + LangChain
|
||||
- 数据库: 腾讯云 MySQL（已配置）
|
||||
- 消息队列: Redis + Celery
|
||||
- AI集成: DeepSeek、OpenAI、Anthropic 多模型支持
|
||||
|
||||
项目结构
|
||||
|
||||
aiagent/
|
||||
├── frontend/ # 前端项目（端口：3001）
|
||||
├── backend/ # 后端项目（端口：8037）
|
||||
├── androidExampleDemo/ # Android示例
|
||||
├── redis_temp/ # Redis临时数据
|
||||
├── saars/ # 智能体资源
|
||||
├── user_data/ # 用户数据
|
||||
└── 大量文档/ # 详细的技术文档和指南
|
||||
|
||||
环境验证 ✅
|
||||
|
||||
- Python 3.12.7 ✓
|
||||
- Node.js 22.13.0 ✓
|
||||
- pnpm 10.33.0 ✓
|
||||
- Redis 运行在 6379 端口 ✓
|
||||
- 虚拟环境已存在 ✓
|
||||
- 前端依赖已安装 ✓
|
||||
|
||||
服务启动状态 ✅
|
||||
|
||||
后端服务
|
||||
|
||||
- 地址: http://localhost:8037
|
||||
- API文档: http://localhost:8037/docs
|
||||
- 健康检查: {"status":"healthy"} ✓
|
||||
- Celery Worker: 已启动 ✓
|
||||
|
||||
前端服务
|
||||
|
||||
- 地址: http://localhost:3001
|
||||
- 代理配置: 已正确指向后端 (8037端口)
|
||||
- CORS配置: 已包含 localhost:3001 ✓
|
||||
|
||||
数据库
|
||||
|
||||
- 腾讯云MySQL: 已连接 ✓
|
||||
- 数据库迁移: 已执行 ✓
|
||||
|
||||
Redis
|
||||
|
||||
- 运行端口: 6379 ✓
|
||||
- 连接状态: 正常 ✓
|
||||
|
||||
访问方式
|
||||
|
||||
1. 前端界面: http://localhost:3001
|
||||
2. 后端API: http://localhost:8037
|
||||
3. API文档: http://localhost:8037/docs（Swagger UI）
|
||||
|
||||
使用说明
|
||||
|
||||
4. 首次访问需注册新用户
|
||||
5. 创建智能体和工作流进行测试
|
||||
6. 所有服务已在后台运行，请勿关闭相关命令行窗口
|
||||
7. 如需停止服务，可结束相关进程或使用脚本中的停止功能
|
||||
|
||||
▎ 注意: 前端实际运行在 3001 端口（非脚本中显示的 3000），这是由于 vite.config.ts 的配置决定的。
|
||||
175
docs/Obsidian笔记体系/Projects/agent/下一步计划0505.md
Normal file
175
docs/Obsidian笔记体系/Projects/agent/下一步计划0505.md
Normal file
@@ -0,0 +1,175 @@
|
||||
---
|
||||
当前进度
|
||||
|
||||
┌─────────┬────────────────────────────────────────┬─────────────────────────────┐
|
||||
│ 阶段 │ 内容 │ 状态 │
|
||||
├─────────┼────────────────────────────────────────┼─────────────────────────────┤
|
||||
│ Phase 1 │ 输出质量验证 + 节点级自动重试 │ ✅ 完成 │
|
||||
├─────────┼────────────────────────────────────────┼─────────────────────────────┤
|
||||
│ Phase 2 │ Orchestrator 入工作流 + 工具级人工审批 │ ✅ 完成 │
|
||||
├─────────┼────────────────────────────────────────┼─────────────────────────────┤
|
||||
│ Phase 3 │ 并行执行 + 进度上报 + 结果缓存 │ ✅ 完成 (含 Bug #1-#5 修复) │
|
||||
├─────────┼────────────────────────────────────────┼─────────────────────────────┤
|
||||
│ Phase 4 │ 降级回退 + 知识共享 + 异步执行 │ 待开发 │
|
||||
└─────────┴────────────────────────────────────────┴─────────────────────────────┘
|
||||
|
||||
---
|
||||
下一步：第四阶段 — 容错与共享
|
||||
|
||||
根据 解决缺失能力计划.md，最后 3 项：
|
||||
|
||||
4.1 降级/回退链
|
||||
|
||||
- AgentLLMConfig 加 fallback_llm 字段
|
||||
- 主模型挂了自动切备用模型
|
||||
- Agent 失败自动切 fallback_agent
|
||||
|
||||
4.2 Agent 间知识共享
|
||||
|
||||
- 新增 GlobalKnowledge 表
|
||||
- Agent 执行完自动提取知识写入全局池
|
||||
- 其他 Agent 初始化时检索全局知识
|
||||
|
||||
4.3 Agent 异步执行
|
||||
|
||||
- execute_agent_task 当前是空壳占位符
|
||||
- 实现真正的 Celery 异步 Agent 执行
|
||||
- 定时调度能真正运行 Agent
|
||||
|
||||
---
|
||||
要开始做 Phase 4 吗？
|
||||
|
||||
✻ Churned for 41s
|
||||
|
||||
❯ 当前系统，还能做些什么需求，进一步提升呢
|
||||
|
||||
Read 2 files, listed 1 directory (ctrl+o to expand)
|
||||
|
||||
● 让我全面梳理一下，结合已有规划文档和架构师/测试/产品经理视角。
|
||||
|
||||
---
|
||||
当前系统还能做的需求全景
|
||||
|
||||
一、已规划的 Phase 4（来自 解决缺失能力计划.md）
|
||||
|
||||
┌─────┬──────────────────┬─────────────────────────────────────────────────────┐
|
||||
│ # │ 需求 │ 说明 │
|
||||
├─────┼──────────────────┼─────────────────────────────────────────────────────┤
|
||||
│ 4.1 │ 降级/回退链 │ 模型挂了自动切备用模型，Agent 失败切 fallback_agent │
|
||||
├─────┼──────────────────┼─────────────────────────────────────────────────────┤
|
||||
│ 4.2 │ Agent 间知识共享 │ 打破记忆隔离，Agent A 学到的东西 Agent B 也能用 │
|
||||
├─────┼──────────────────┼─────────────────────────────────────────────────────┤
|
||||
│ 4.3 │ Agent 异步执行 │ execute_agent_task 是空壳，定时调度无法真正异步执行 │
|
||||
└─────┴──────────────────┴─────────────────────────────────────────────────────┘
|
||||
|
||||
▎ 这是最直接的下一步，按计划走。
|
||||
|
||||
---
|
||||
二、监控告警前端（后端已完成，前端缺失）
|
||||
|
||||
后端 API 全部就绪，前端一个页面都没写：
|
||||
|
||||
- 系统监控面板 — CPU/内存/磁盘/执行统计图表
|
||||
- 告警规则管理 — 规则 CRUD + 启用/禁用
|
||||
- 告警日志查看 — 告警历史 + 通知配置
|
||||
|
||||
▎ 平台可观测性的最后一公里。
|
||||
|
||||
---
|
||||
三、生产就绪（DevOps / 运维）
|
||||
|
||||
┌──────────────────────┬────────────────────────────────────────────┐
|
||||
│ 需求 │ 说明 │
|
||||
├──────────────────────┼────────────────────────────────────────────┤
|
||||
│ Docker 生产环境配置 │ 目前只有 dev compose，缺 prod 配置 │
|
||||
├──────────────────────┼────────────────────────────────────────────┤
|
||||
│ Prometheus + Grafana │ 指标收集 + 仪表板（业务指标 + 系统指标） │
|
||||
├──────────────────────┼────────────────────────────────────────────┤
|
||||
│ ELK 日志聚合 │ 日志集中查询分析，替代目前本地 backend.log │
|
||||
├──────────────────────┼────────────────────────────────────────────┤
|
||||
│ CI/CD 流水线 │ GitHub Actions：自动测试 → 构建 → 部署 │
|
||||
├──────────────────────┼────────────────────────────────────────────┤
|
||||
│ API 限流 │ 防止滥用，保护后端 │
|
||||
├──────────────────────┼────────────────────────────────────────────┤
|
||||
│ 密钥管理 │ 敏感信息加密存储，不用明文 .env │
|
||||
└──────────────────────┴────────────────────────────────────────────┘
|
||||
|
||||
---
|
||||
四、用户体验增强
|
||||
|
||||
┌────────────────┬─────────────────────────────────────────┐
|
||||
│ 需求 │ 说明 │
|
||||
├────────────────┼─────────────────────────────────────────┤
|
||||
│ 工作流自动布局 │ 节点一键对齐，美观排列 │
|
||||
├────────────────┼─────────────────────────────────────────┤
|
||||
│ 节点搜索/筛选 │ 复杂工作流快速定位节点 │
|
||||
├────────────────┼─────────────────────────────────────────┤
|
||||
│ Agent 快速测试 │ 在配置页直接测试 Agent，不用跳到对话页 │
|
||||
├────────────────┼─────────────────────────────────────────┤
|
||||
│ Agent 使用统计 │ 每个 Agent 的调用次数、成功率、平均耗时 │
|
||||
├────────────────┼─────────────────────────────────────────┤
|
||||
│ 移动端适配 │ 至少执行状态查看、Agent 对话 │
|
||||
└────────────────┴─────────────────────────────────────────┘
|
||||
|
||||
---
|
||||
五、高级功能（差异化竞争）
|
||||
|
||||
┌─────────────────┬───────────────────────────────────────────────┐
|
||||
│ 需求 │ 说明 │
|
||||
├─────────────────┼───────────────────────────────────────────────┤
|
||||
│ 主控台/应用商店 │ 选模板 → 填参数 → 执行 → 看结果，面向业务用户 │
|
||||
├─────────────────┼───────────────────────────────────────────────┤
|
||||
│ 统一 DSL │ 不同模板复用统一输入契约，一套输入驱动多模板 │
|
||||
├─────────────────┼───────────────────────────────────────────────┤
|
||||
│ 成本预算治理 │ 按 Agent 设置 token/调用预算，超限熔断 │
|
||||
├─────────────────┼───────────────────────────────────────────────┤
|
||||
│ 插件系统 │ 第三方开发自定义节点，插件市场上架 │
|
||||
├─────────────────┼───────────────────────────────────────────────┤
|
||||
│ 多租户支持 │ SaaS 化，数据隔离 + 资源配额 │
|
||||
└─────────────────┴───────────────────────────────────────────────┘
|
||||
|
||||
---
|
||||
六、质量保障
|
||||
|
||||
┌────────────────┬───────────────────────────────────┐
|
||||
│ 需求 │ 说明 │
|
||||
├────────────────┼───────────────────────────────────┤
|
||||
│ 单元测试覆盖率 │ 当前有框架但覆盖率低，目标 80%+ │
|
||||
├────────────────┼───────────────────────────────────┤
|
||||
│ E2E 测试 │ Playwright 覆盖核心用户流程 │
|
||||
├────────────────┼───────────────────────────────────┤
|
||||
│ 性能压测 │ Locust/k6 压测 API，找瓶颈 │
|
||||
├────────────────┼───────────────────────────────────┤
|
||||
│ 安全扫描 │ OWASP ZAP + SQLMap + 依赖漏洞检查 │
|
||||
└────────────────┴───────────────────────────────────┘
|
||||
|
||||
---
|
||||
七、Agent 能力边界拓展
|
||||
|
||||
┌──────────────────┬───────────────────────────────────────────────┐
|
||||
│ 需求 │ 说明 │
|
||||
├──────────────────┼───────────────────────────────────────────────┤
|
||||
│ 多模态 Agent │ 支持图片识别、语音输入（tessdata 目录已存在） │
|
||||
├──────────────────┼───────────────────────────────────────────────┤
|
||||
│ Agent 协作工作台 │ 可视化编排多 Agent 协作流程 │
|
||||
├──────────────────┼───────────────────────────────────────────────┤
|
||||
│ Agent 技能商店 │ Agent 发布到公共市场，共享复用 │
|
||||
└──────────────────┴───────────────────────────────────────────────┘
|
||||
|
||||
---
|
||||
建议优先级
|
||||
|
||||
第一优先（生产就绪）：Phase 4 + 监控告警前端 + Docker 生产配置
|
||||
第二优先（体验提升）：工作流自动布局 + Agent 快速测试 + 主控台
|
||||
第三优先（竞争壁垒）：插件系统 + 多租户 + 统一 DSL
|
||||
第四优先（质量保障）：测试覆盖率 + E2E + 性能压测
|
||||
|
||||
总共约 20+ 个可做需求，看你想先往哪个方向发力？是按计划继续做 Phase 4，还是先补监控告警前端，还是往生产就绪方向走？
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
将这些需求登记到工单平台（Gitea） D:\aaa\aiagent\docs\平台资料.md
|
||||
|
||||
可参考D:\aaa\aiagent\docs\创建工单总结.md
|
||||
45
docs/Obsidian笔记体系/Projects/agent/多agent协作.md
Normal file
45
docs/Obsidian笔记体系/Projects/agent/多agent协作.md
Normal file
@@ -0,0 +1,45 @@
|
||||
当前系统多 Agent 协作能力
|
||||
|
||||
一、四种协作模式（后端已实现，前端暂无 UI）
|
||||
|
||||
核心在 backend/app/agent_runtime/orchestrator.py，AgentOrchestrator 支持：
|
||||
|
||||
┌────────────┬────────────────┬─────────────────────────────────────────────────────────────────────────────┐
|
||||
│ 模式 │ 机制 │ 说明 │
|
||||
├────────────┼────────────────┼─────────────────────────────────────────────────────────────────────────────┤
|
||||
│ route │ 路由分发 │ Router Agent 分析问题 → 挑选最合适的 Specialist Agent → 委托执行 → 返回结果 │
|
||||
├────────────┼────────────────┼─────────────────────────────────────────────────────────────────────────────┤
|
||||
│ sequential │ 顺序流水线 │ Agent A → B → C 依次执行，上一轮的输出作为下一轮的输入 │
|
||||
├────────────┼────────────────┼─────────────────────────────────────────────────────────────────────────────┤
|
||||
│ debate │ 并行辩论 │ 多个 Agent 同时回答同一问题，Aggregator Agent 综合各方观点输出最终答案 │
|
||||
├────────────┼────────────────┼─────────────────────────────────────────────────────────────────────────────┤
|
||||
│ pipeline │ 规划-执行-审核 │ Planner 拆解任务 → Executor 逐步执行 → Reviewer 审核结果 │
|
||||
└────────────┴────────────────┴─────────────────────────────────────────────────────────────────────────────┘
|
||||
|
||||
API 端点：POST /api/v1/agent-chat/orchestrate
|
||||
|
||||
二、工作流 DAG 中的 Agent 协作
|
||||
|
||||
在 backend/app/services/workflow_engine.py 中，工作流支持两种方式引入 Agent：
|
||||
|
||||
- agent 节点：在工作流画布上拖入一个 Agent 节点，内部运行完整的 ReAct 循环（思考→调工具→再思考），输出传给下游节点
|
||||
- subworkflow / invoke_agent 节点：一个工作流/Agent 调用另一个工作流或 Agent
|
||||
作为子执行，支持父子执行记录追踪和深度限制（防止无限递归）
|
||||
|
||||
三、多用户协同编辑（Workflow 画布）
|
||||
|
||||
backend/app/api/collaboration.py 支持多人在同一工作流画布上实时协作（类似 Figma），通过 WebSocket
|
||||
广播节点/连线的增删改操作。
|
||||
|
||||
四、本质限制
|
||||
|
||||
- Agent 之间没有共享记忆，各自独立
|
||||
- Agent 之间没有直接消息传递，全靠 Orchestrator 或工作流 DAG 数据流中转
|
||||
- 没有"团队/swarm"概念，Agent 不能自组织
|
||||
- 没有 call_agent 工具，Agent 不能像调工具一样调用另一个 Agent
|
||||
|
||||
---
|
||||
你现在要用哪种协作模式？ 比如：
|
||||
- 用 route 模式做"路由 + 专业分工"（橙子助手路由到不同专业 Agent）
|
||||
- 用 debate 模式做"多视角讨论"
|
||||
- 在工作流画布上用 agent/subworkflow 节点串联多个 Agent
|
||||
37
docs/Obsidian笔记体系/Projects/agent/天工智能体定位.md
Normal file
37
docs/Obsidian笔记体系/Projects/agent/天工智能体定位.md
Normal file
@@ -0,0 +1,37 @@
|
||||
搜索到 20+ 处使用"低代码智能体平台"的地方。在改之前，先确认下你想要什么风格的名字。以下是几个建议：
|
||||
|
||||
┌────────────────┬────────┬─────────────────────────────────────────────────────┐
|
||||
│ 名称 │ 风格 │ 含义 │
|
||||
├────────────────┼────────┼─────────────────────────────────────────────────────┤
|
||||
│ 知行智能体平台 │ 哲学风 │ 知行合一，知（知识库/RAG）+ 行（工具调用/自主执行） │
|
||||
├────────────────┼────────┼─────────────────────────────────────────────────────┤
|
||||
│ 自主智能体平台 │ 直白风 │ 直接体现从"低代码编排"到"自主 ReAct Agent"的进化 │
|
||||
├────────────────┼────────┼─────────────────────────────────────────────────────┤
|
||||
│ 灵枢智能体平台 │ 禅意风 │ 灵（AI智能）+ 枢（中枢/编排），与"灵犀"呼应 │
|
||||
├────────────────┼────────┼─────────────────────────────────────────────────────┤
|
||||
│ 元智智能体平台 │ 极客风 │ 元（Meta，多Agent协作）+ 智（AI） │
|
||||
├────────────────┼────────┼─────────────────────────────────────────────────────┤
|
||||
│ 智行AI工坊 │ 务实风 │ 智（智能）+ 行（执行）+ 工坊（持续打磨） │
|
||||
└────────────────┴────────┴─────────────────────────────────────────────────────┘
|
||||
|
||||
你倾向哪个方向？或者你有自己的想法？
|
||||
|
||||
✻ Sautéed for 37s
|
||||
|
||||
❯ 未来的方向包含上面所有，再想个名字吧
|
||||
|
||||
● 综合所有方向（自主、知行、多智能体、工坊、灵枢），体现"包罗万象、自主创造"的定位：
|
||||
|
||||
┌──────┬──────────────────────────────────────────────────────────────────────┐
|
||||
│ 名称 │ 出处/寓意 │
|
||||
├──────┼──────────────────────────────────────────────────────────────────────┤
|
||||
│ 天工 │ 《天工开物》— 巧夺天工，万物皆可造。自然力+人工智能力=创造万物的工匠 │
|
||||
├──────┼──────────────────────────────────────────────────────────────────────┤
|
||||
│ 元枢 │ 元（Meta/起源）+ 枢（中枢/编排）— 智能体的元起点与调度中枢 │
|
||||
├──────┼──────────────────────────────────────────────────────────────────────┤
|
||||
│ 万象 │ 包罗万象 — 多模态、多Agent、多工具、多场景，无所不包 │
|
||||
├──────┼──────────────────────────────────────────────────────────────────────┤
|
||||
│ 开物 │ 《天工开物》+ "开物成务" — 打通万物，成就事业 │
|
||||
├──────┼──────────────────────────────────────────────────────────────────────┤
|
||||
│ 无极 │ 无极生太极 — 无限可能，无边界的自主智能 │
|
||||
└──────┴──────────────────────────────────────────────────────────────────────┘
|
||||
@@ -0,0 +1,42 @@
|
||||
你这个问题很关键。先按你的意思把“类似 openclaw”理解为：一个通用主 Agent，能自主规划、拆任务、调工具、必要时再拉起子 Agent 持续执行。
|
||||
和你现在这套平台相比，核心区别在下面几块：
|
||||
|
||||
## 主要区别
|
||||
|
||||
- 执行模型
|
||||
|
||||
- 现在平台：以工作流节点为中心（Start/LLM/Cache/Loop 等），流程可视化、可控。
|
||||
- openclaw 类：以**Agent循环（plan-act-observe）**为中心，动态决策更强，流程不一定预先画好。
|
||||
- 多 Agent 编排
|
||||
|
||||
- 现在平台：主流程里“调用另一个 Agent/子工作流”能力还偏弱（你代码里 `subworkflow` 还是占位）。
|
||||
- openclaw 类：通常把“委派给子 Agent”作为一等能力，任务分工更自然。
|
||||
- 动态创建 Agent
|
||||
|
||||
- 现在平台：更适合“模板复制 + 配置更新”，不适合对话中从零生成完整 workflow JSON。
|
||||
- openclaw 类：更强调运行时动态角色切换/创建执行单元（但也要做好安全隔离）。
|
||||
- 工程治理与可控性
|
||||
|
||||
- 现在平台：审计、日志、节点级可观测性好，业务方容易托管。
|
||||
- openclaw 类：自主性强，但要额外补“边界控制”（权限、预算、回滚、人工确认）。
|
||||
- 适配场景
|
||||
|
||||
- 现在平台：固定业务流程、可配置客服/工具编排、可视化运维。
|
||||
- openclaw 类：复杂研发任务、探索式问题、需要“先想再干再反思”的长链任务。
|
||||
|
||||
## 你现在平台的优势（别丢）
|
||||
|
||||
- 节点化可视化 + 权限体系 + 执行日志，这些是企业化落地很重要的。
|
||||
- 对“稳定复用场景”非常好（客服、固定流程自动化）。
|
||||
|
||||
## 如果你要“做成 openclaw 风格”，最小改造路线
|
||||
|
||||
- 先做一个 Main Agent（路由官）：只负责意图识别 + 任务分解 + 选择模板 Agent。
|
||||
- 后端补一个真实的 `invoke_agent` 能力（而不是占位 `subworkflow`）。
|
||||
- 子 Agent 优先走“模板复制”而不是“从零造图”。
|
||||
- 加 4 个护栏：`max_steps`、超时、可用工具白名单、关键操作人工确认。
|
||||
|
||||
---
|
||||
|
||||
一句话：你现在平台更像“可编排的业务工作流系统”，openclaw 更像“高自治任务执行体”。
|
||||
你可以在不推翻现平台的前提下，先把“主 Agent + 子 Agent 调度”做出来，就已经很接近 openclaw 的体验了。
|
||||
170
docs/Obsidian笔记体系/Projects/agent/新方向.md
Normal file
170
docs/Obsidian笔记体系/Projects/agent/新方向.md
Normal file
@@ -0,0 +1,170 @@
|
||||
❯ 当前项目，需要一个主manin agent作为入口吗，我想让这个平台能自主的干事情，比如我给他一个飞书账户，它可以在上面和人一样的使用
|
||||
|
||||
● 这是个很好的方向。你描述的本质上是一个自主智能体操作系统——天工平台作为大脑，飞书作为它的"手和眼睛"。
|
||||
|
||||
是否需要 Main Agent？
|
||||
|
||||
需要，但不是传统意义上的"入口 Agent"。 更好的架构是一个 编排层（Orchestration Layer），它不是一个 Agent，而是平台的自主运行内核：
|
||||
|
||||
┌─────────────────────────────────────────────────┐
|
||||
│ 天工平台 │
|
||||
│ ┌───────────────────────────────────────────┐ │
|
||||
│ │ 编排内核 (Orchestrator) │ │
|
||||
│ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────────┐ │ │
|
||||
│ │ │目标 │ │任务 │ │记忆 │ │自主决策 │ │ │
|
||||
│ │ │解析 │ │编排 │ │系统 │ │引擎 │ │ │
|
||||
│ │ └─────┘ └─────┘ └─────┘ └─────────┘ │ │
|
||||
│ └───────────────────────────────────────────┘ │
|
||||
│ │ │ │ │
|
||||
│ ┌────┴────┐ ┌───┴───┐ ┌───┴────┐ │
|
||||
│ │ 橙子助手 │ │ 灵犀 │ │ 苏瑶 │ ... (36个) │
|
||||
│ └─────────┘ └───────┘ └────────┘ │
|
||||
│ │ │ │ │
|
||||
│ ┌────┴──────────┴──────────┴────┐ │
|
||||
│ │ 工具层 (40+ tools) │ │
|
||||
│ │ 飞书消息 | 邮件 | 搜索 | 文件 │ │
|
||||
│ └───────────────────────────────┘ │
|
||||
└─────────────────────────────────────────────────┘
|
||||
|
||||
飞书作为"人机接口"要解决的核心问题
|
||||
|
||||
给 Agent 一个飞书账号让它像人一样使用，需要三个能力：
|
||||
|
||||
1. 飞书消息的"读"能力（已有基础）
|
||||
|
||||
现在各机器人只能收 p2p 单聊消息。要像人一样，还需要：
|
||||
|
||||
┌────────────────┬──────┬──────────────────────────┐
|
||||
│ 能力 │ 现状 │ 需要 │
|
||||
├────────────────┼──────┼──────────────────────────┤
|
||||
│ 接收单聊消息 │ 已有 │ — │
|
||||
├────────────────┼──────┼──────────────────────────┤
|
||||
│ 接收群聊 @消息 │ 无 │ 监听群聊，被@时响应 │
|
||||
├────────────────┼──────┼──────────────────────────┤
|
||||
│ 读取群聊历史 │ 无 │ 获取群聊上下文，理解讨论 │
|
||||
├────────────────┼──────┼──────────────────────────┤
|
||||
│ 主动发消息到群 │ 无 │ 推送日报、告警、回复 │
|
||||
└────────────────┴──────┴──────────────────────────┘
|
||||
|
||||
2. 飞书的"写"能力（部分已有）
|
||||
|
||||
┌───────────────┬──────┬──────────────────┐
|
||||
│ 能力 │ 现状 │ 需要 │
|
||||
├───────────────┼──────┼──────────────────┤
|
||||
│ 发送文本/卡片 │ 已有 │ — │
|
||||
├───────────────┼──────┼──────────────────┤
|
||||
│ 创建飞书文档 │ 无 │ 自动写报告、周报 │
|
||||
├───────────────┼──────┼──────────────────┤
|
||||
│ 创建/管理日程 │ 无 │ 安排会议、提醒 │
|
||||
├───────────────┼──────┼──────────────────┤
|
||||
│ 审批流操作 │ 无 │ 自动提交/审批 │
|
||||
└───────────────┴──────┴──────────────────┘
|
||||
|
||||
3. 自主性的"脑"（核心缺口）
|
||||
|
||||
这才是关键——Agent 什么时候做什么事：
|
||||
|
||||
用户: "帮我关注公司群里的技术讨论，每天18:00总结"
|
||||
|
||||
编排内核:
|
||||
08:00 启动"群聊监听"任务，持续监听目标群
|
||||
18:00 触发"每日总结"Agent，读取今日群聊记录
|
||||
18:05 生成总结报告，发送到用户单聊
|
||||
18:06 归档到知识库
|
||||
|
||||
建议的演进路线
|
||||
|
||||
第一阶段：飞书能力补全（1-2周）
|
||||
- 群聊消息监听（接收+发送）
|
||||
- 飞书文档 API（创建/编辑文档）
|
||||
- 飞书日历 API（创建/管理日程）
|
||||
|
||||
第二阶段：编排内核（2-3周）
|
||||
- 目标管理：用户用自然语言设定长期目标
|
||||
- 任务编排：自动拆解目标 → 子任务 → 分配给不同 Agent
|
||||
- 自主触发：基于时间/事件/条件自动启动 Agent
|
||||
|
||||
第三阶段：自主学习（持续）
|
||||
- 从交互中学习用户偏好
|
||||
- Agent 间知识共享和协作
|
||||
- 主动发现问题并提出建议
|
||||
|
||||
---
|
||||
要开始从哪个阶段动手？我建议先把飞书的群聊和文档能力补上，这是 Agent "像人一样用飞书"的基础。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
三个真正有价值的方向
|
||||
|
||||
方向一：数字员工工厂
|
||||
|
||||
不是"一个飞书账号"，而是一支 AI 团队。
|
||||
|
||||
用户: "这个季度我们要把用户留存率从60%提到75%"
|
||||
|
||||
天工自动:
|
||||
1. 数据分析Agent → 拉数据，找留存漏斗瓶颈
|
||||
2. 竞品调研Agent → 搜索竞品留存策略
|
||||
3. 方案Agent → 基于分析结果，生成3个方案
|
||||
4. A/B测试Agent → 设计方案、监控数据
|
||||
5. 复盘Agent → 一周后自动复盘，给出结论
|
||||
|
||||
用户看到的不是聊天记录，而是一个正在运作的迷你团队。
|
||||
|
||||
核心能力：目标 → 自动拆解 → 多Agent并行执行 → 结果汇总。人只需要定方向和做决策。
|
||||
|
||||
---
|
||||
方向二：个人数字分身
|
||||
|
||||
让天工学你——不是学怎么回消息，而是学你怎么思考、怎么决策。
|
||||
|
||||
Day 1-30: 天工观察你的工作模式
|
||||
- 你怎么处理邮件
|
||||
- 你怎么审核代码
|
||||
- 你怎么写文档
|
||||
- 你怎么做决策
|
||||
|
||||
Day 30+: 开始代理执行
|
||||
- "这个PR你看下" → 自动审核，标注问题，建议合入
|
||||
- "这个合同审一下" → 对照历史合同，标记风险条款
|
||||
- "这个需求评估一下" → 拉历史数据，给工时预估
|
||||
|
||||
你只需要对关键决策点头或摇头。
|
||||
|
||||
核心能力：从观察到模仿 → 从模仿到代理 → 从代理到自主。这是真正的 AI 能力曲线。
|
||||
|
||||
对比飞书路线：飞书是"给 AI 一只手"，数字分身是"给 AI 一个角色"。
|
||||
|
||||
---
|
||||
方向三：知识自进化系统
|
||||
|
||||
这个方向最大胆——让天工成为一个会自己变聪明的平台。
|
||||
|
||||
传统系统: 人类写规则 → 系统执行
|
||||
天工: 系统观察 → 系统总结 → 系统改进 → 系统变强
|
||||
|
||||
具体表现:
|
||||
- Agent A 解决了一个棘手bug，自动沉淀为知识，所有Agent受益
|
||||
- 发现某个工作流经常卡在某节点，自动优化流程
|
||||
- 用户反馈"这个回答不好"，自动调整策略，不再犯同样错误
|
||||
- 监控到新工具发布，自动学习并集成
|
||||
|
||||
---
|
||||
我的判断
|
||||
|
||||
┌──────────────┬──────┬──────┬───────────────────────┬──────────┐
|
||||
│ 方向 │ 价值 │ 难度 │ 差异化 │ 建议优先 │
|
||||
├──────────────┼──────┼──────┼───────────────────────┼──────────┤
|
||||
│ 飞书增强 │ 中 │ 低 │ 低（钉钉/企微都能做） │ ❌ │
|
||||
├──────────────┼──────┼──────┼───────────────────────┼──────────┤
|
||||
│ 数字员工工厂 │ 极高 │ 中 │ 极高 │ ✅ 首选 │
|
||||
├──────────────┼──────┼──────┼───────────────────────┼──────────┤
|
||||
│ 个人数字分身 │ 极高 │ 高 │ 高 │ 中期 │
|
||||
├──────────────┼──────┼──────┼───────────────────────┼──────────┤
|
||||
│ 知识自进化 │ 极高 │ 极高 │ 极高 │ 长期愿景 │
|
||||
└──────────────┴──────┴──────┴───────────────────────┴──────────┘
|
||||
|
||||
数字员工工厂是三者中最适合现在就动手的——它基于现有的 Agent 编排能力、36个技能
|
||||
Agent、工作流引擎，不需要从零开始。而且它的产品形态非常清晰：给平台一个目标，它给你一支团队。
|
||||
1
docs/Obsidian笔记体系/Projects/agent/未来规划.md
Normal file
1
docs/Obsidian笔记体系/Projects/agent/未来规划.md
Normal file
@@ -0,0 +1 @@
|
||||
如需再扩展：同一 Agent 多人协作、每人用自己 Key，需要改归属策略（例如按登录用户注入 `trusted_uid`），可以再说一下你的产品规则。
|
||||
124
docs/Obsidian笔记体系/Projects/agent/苏瑶记忆方案.md
Normal file
124
docs/Obsidian笔记体系/Projects/agent/苏瑶记忆方案.md
Normal file
@@ -0,0 +1,124 @@
|
||||
> 这种记忆策略，优缺点，是否还有更好的记忆解决方案？
|
||||
|
||||
● 聊记忆策略之前，先看你当前这套架构实际怎么跑的：
|
||||
|
||||
---
|
||||
当前记忆架构拆解
|
||||
|
||||
┌─────────────────────────────────────────────┐
|
||||
│ 会话内消息 (20条) │
|
||||
│ 用户: 今天好累 ← 直接可引用 │
|
||||
│ 苏瑶: 怎么了呀，跟我说说 ← 20条满后FIFO │
|
||||
│ ...15条后... │
|
||||
│ 用户: 刚才说的那个方案 ← 第18条还在 │
|
||||
│ 苏瑶: (记得) │
|
||||
│ 用户: 上周聊的那个呢？ ← 第22条已丢弃 │
|
||||
└─────────────────────────────────────────────┘
|
||||
↓ LLM每2轮触发压缩
|
||||
┌─────────────────────────────────────────────┐
|
||||
│ MySQL 长期记忆 (永久) │
|
||||
│ { │
|
||||
│ "user_profile": {"job": "程序员", ...}, │
|
||||
│ "key_facts": ["加班多","喜欢猫"], │
|
||||
│ "topics": ["工作压力","养猫"], │
|
||||
│ "summary": "用户最近工作压力大..." │
|
||||
│ } │
|
||||
└─────────────────────────────────────────────┘
|
||||
↓ 每条对话 → embedding
|
||||
┌─────────────────────────────────────────────┐
|
||||
│ MySQL 向量记忆 (50条) │
|
||||
│ 新对话: "最近睡眠不好" │
|
||||
│ → embedding 匹配到之前聊的"失眠"相关 │
|
||||
│ → 注入 Top-5 相关性最高的历史片段 │
|
||||
└─────────────────────────────────────────────┘
|
||||
|
||||
---
|
||||
优缺点分析
|
||||
|
||||
短期记忆（20条滑动窗口）
|
||||
|
||||
┌───────────────────────┬───────────────────────────────────────────────┐
|
||||
│ 优点 │ 缺点 │
|
||||
├───────────────────────┼───────────────────────────────────────────────┤
|
||||
│ 实现简单，无额外成本 │ 20条太少，苏瑶场景下一段深度倾诉就20轮以上 │
|
||||
├───────────────────────┼───────────────────────────────────────────────┤
|
||||
│ 保证 LLM context 不爆 │ FIFO 简单裁剪，无重要性判断，可能丢了关键信息 │
|
||||
├───────────────────────┼───────────────────────────────────────────────┤
|
||||
│ 延迟低 │ 无法区分"刚说的重点"和"闲聊寒暄" │
|
||||
└───────────────────────┴───────────────────────────────────────────────┘
|
||||
|
||||
长期记忆（LLM 压缩 → MySQL）
|
||||
|
||||
┌───────────────────────┬─────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ 优点 │ 缺点 │
|
||||
├───────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ 永久存储，跨会话可用 │ 压缩是有损的，LLM 可能提取错误或遗漏关键信息 │
|
||||
├───────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ 自动提取画像和事实 │ 每2轮就触发一次 LLM 调用→额外 token 消耗 │
|
||||
├───────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ 启动时注入 system │ 压缩后的 JSON 很抽象："user_profile": {"mood": "压力大"} — │
|
||||
│ prompt │ 苏瑶只知道"用户压力大"，但忘了是为什么压力大、当时怎么安慰的 │
|
||||
└───────────────────────┴─────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
|
||||
向量记忆（Embedding + 语义搜索）
|
||||
|
||||
┌────────────────────────────┬───────────────────────────────────────────────────┐
|
||||
│ 优点 │ 缺点 │
|
||||
├────────────────────────────┼───────────────────────────────────────────────────┤
|
||||
│ 语义匹配，能找到"相关"历史 │ 只搜最近 50条，时间久了旧记忆会被新对话挤出 │
|
||||
├────────────────────────────┼───────────────────────────────────────────────────┤
|
||||
│ 不依赖关键词匹配 │ embedding 质量依赖 SiliconFlow 模型，中文效果一般 │
|
||||
├────────────────────────────┼───────────────────────────────────────────────────┤
|
||||
│ 检索效率高 │ 只存不更新，重复信息越来越多 │
|
||||
└────────────────────────────┴───────────────────────────────────────────────────┘
|
||||
|
||||
---
|
||||
核心问题
|
||||
|
||||
三层记忆之间没有协同：
|
||||
|
||||
1. 短期记忆丢了的信息 → 长期记忆只有抽象画像，具体对话丢失
|
||||
2. 向量记忆只存不删 → 累积后相似内容太多，检索质量下降
|
||||
3. 缺少情感状态追踪 — 苏瑶是情感陪聊，但记忆系统完全没考虑情绪维度
|
||||
|
||||
---
|
||||
更好的方案（分三档）
|
||||
|
||||
方案 A：低成本快改（今天就能做）
|
||||
|
||||
改动当前参数，针对苏瑶场景优化：
|
||||
|
||||
- max_history 20→40（深度对话不至于丢上下文）
|
||||
- 压缩触发从 2 轮→8 轮（减少 LLM 调用，提高压缩质量）
|
||||
- 向量记忆检索范围 50→200（保留更久的历史）
|
||||
|
||||
方案 B：中等改造（记忆分层 + 情绪追踪）
|
||||
|
||||
在不改架构的前提下，加两个模块：
|
||||
|
||||
1. 记忆分级存储
|
||||
核心记忆（永久）: 用户名、职业、重要事件（生日、重大决策）
|
||||
情景记忆（30天）: 具体对话场景、当时聊了什么
|
||||
情感记忆（7天）: 最近心情走向、什么话题触发情绪波动
|
||||
- 不同 TTL 的 Redis key，定期归档到 MySQL
|
||||
- 苏瑶启动时按优先级加载
|
||||
|
||||
2. 情绪时间线
|
||||
- 每次对话记录 {emotion: "低落", topic: "工作", time: "2026-05-02"}
|
||||
- 苏瑶下次能说："上次聊到工作你好像不太开心，最近好点了吗？"
|
||||
|
||||
方案 C：理想方案（外挂知识库 + RAG）
|
||||
|
||||
适合有规模要求的场景：
|
||||
|
||||
- Milvus / Qdrant 替代 MySQL 存向量（检索速度提升 10x+）
|
||||
- Mem0 / Memobase 开源记忆层，自动做实体抽取 + 关系图谱
|
||||
- GraphRAG 构建用户知识图谱：用户--[关系]-->关键事件--[关联]-->情绪
|
||||
|
||||
---
|
||||
建议
|
||||
|
||||
对苏瑶当前阶段，方案 A 是最务实的，改3个参数就能让体验明显提升。方案 B
|
||||
值得认真考虑，尤其情绪时间线对情感陪聊是质的飞跃。
|
||||
|
||||
要我先把方案 A 的改动做了？
|
||||
250
docs/Obsidian笔记体系/Projects/agent/项目价值评估.md
Normal file
250
docs/Obsidian笔记体系/Projects/agent/项目价值评估.md
Normal file
@@ -0,0 +1,250 @@
|
||||
● 天工智能体平台 — 项目价值评估报告
|
||||
|
||||
---
|
||||
一、代码规模与技术投入
|
||||
|
||||
┌──────────────────┬──────────────────────┐
|
||||
│ 维度 │ 数据 │
|
||||
├──────────────────┼──────────────────────┤
|
||||
│ 后端 Python 文件 │ 273 个，约 69,000 行 │
|
||||
├──────────────────┼──────────────────────┤
|
||||
│ 前端 Vue/TS 文件 │ 49 个，约 31,000 行 │
|
||||
├──────────────────┼──────────────────────┤
|
||||
│ 数据库模型 │ 32 个 │
|
||||
├──────────────────┼──────────────────────┤
|
||||
│ API 路由 │ 33 个 │
|
||||
├──────────────────┼──────────────────────┤
|
||||
│ 页面/路由 │ 29 个 │
|
||||
├──────────────────┼──────────────────────┤
|
||||
│ 内置工具函数 │ 79 个 │
|
||||
├──────────────────┼──────────────────────┤
|
||||
│ 工作流引擎 │ 6,188 行 单体文件 │
|
||||
├──────────────────┼──────────────────────┤
|
||||
│ 总代码量 │ ~10 万行 │
|
||||
└──────────────────┴──────────────────────┘
|
||||
|
||||
评估: 这是一个单人/小团队项目中的大型全栈系统，投入约 6-12 人月工作量。
|
||||
|
||||
---
|
||||
二、技术架构评分
|
||||
|
||||
┌────────────┬───────┬──────────────────────────────────────────────────────────────────────────────┐
|
||||
│ 维度 │ 评分 │ 说明 │
|
||||
├────────────┼───────┼──────────────────────────────────────────────────────────────────────────────┤
|
||||
│ 架构完整性 │ ★★★★☆ │ 前后端分离、异步任务(Celery)、WebSocket、SSE流式、RAG向量检索、工作流DAG引擎 │
|
||||
├────────────┼───────┼──────────────────────────────────────────────────────────────────────────────┤
|
||||
│ 技术选型 │ ★★★★☆ │ Vue3+FastAPI+MySQL+Redis+Celery，成熟且适合中小团队 │
|
||||
├────────────┼───────┼──────────────────────────────────────────────────────────────────────────────┤
|
||||
│ 代码质量 │ ★★★☆☆ │ 核心逻辑扎实(Agent ReAct循环、工作流引擎)，但缺乏单元测试、存在安全漏洞 │
|
||||
├────────────┼───────┼──────────────────────────────────────────────────────────────────────────────┤
|
||||
│ 可扩展性 │ ★★★★☆ │ 插件市场、工具注册表、模型配置分离、多租户用户体系 │
|
||||
├────────────┼───────┼──────────────────────────────────────────────────────────────────────────────┤
|
||||
│ 文档完善度 │ ★★★★★ │ 8个文档文件，覆盖快速开始/架构/开发/部署/API/贡献 │
|
||||
└────────────┴───────┴──────────────────────────────────────────────────────────────────────────────┘
|
||||
|
||||
---
|
||||
三、功能深度分析
|
||||
|
||||
核心竞争力（差异化功能）
|
||||
|
||||
┌──────────────────────┬──────┬───────────────────────────────────────────────────────┐
|
||||
│ 功能 │ 深度 │ 价值 │
|
||||
├──────────────────────┼──────┼───────────────────────────────────────────────────────┤
|
||||
│ Agent ReAct 自主循环 │ 深 │ 支持 LLM 工具调用 → 结果反馈 → 自我修正的完整闭环 │
|
||||
├──────────────────────┼──────┼───────────────────────────────────────────────────────┤
|
||||
│ 可视化工作流 DAG │ 深 │ 6,188行引擎，支持条件分支/循环/审批/LLM/HTTP/代码节点 │
|
||||
├──────────────────────┼──────┼───────────────────────────────────────────────────────┤
|
||||
│ 多 Agent 编排 │ 深 │ 5种模式(串行/辩论/路由/流水线/图)，Agent间知识共享 │
|
||||
├──────────────────────┼──────┼───────────────────────────────────────────────────────┤
|
||||
│ 飞书深度集成 │ 深 │ 4个独立飞书应用+WebSocket实时连接，支持6个Bot │
|
||||
├──────────────────────┼──────┼───────────────────────────────────────────────────────┤
|
||||
│ 数字孪生/数字员工 │ 中 │ 概念新颖，有独立页面但实现较薄 │
|
||||
├──────────────────────┼──────┼───────────────────────────────────────────────────────┤
|
||||
│ 知识进化系统 │ 中 │ RAG检索+学习模式提取+向量记忆，但刚刚完成基础架构 │
|
||||
├──────────────────────┼──────┼───────────────────────────────────────────────────────┤
|
||||
│ 定时调度 │ 完整 │ Cron表达式+Agent自动执行+飞书推送 │
|
||||
├──────────────────────┼──────┼───────────────────────────────────────────────────────┤
|
||||
│ 行为采集学习 │ 初 │ 用户行为记录，但反馈学习链路未闭合 │
|
||||
└──────────────────────┴──────┴───────────────────────────────────────────────────────┘
|
||||
|
||||
通用功能覆盖
|
||||
|
||||
工具市场、模板市场、数据源管理、模型配置、权限管理、监控仪表板、告警规则、审批流、执行历史——标准企业级平台功能齐全
|
||||
。
|
||||
|
||||
---
|
||||
四、商业化潜力评估
|
||||
|
||||
┌────────────┬──────────────────────────────────────────────────┐
|
||||
│ 因素 │ 判断 │
|
||||
├────────────┼──────────────────────────────────────────────────┤
|
||||
│ 目标用户 │ 企业/团队需要AI自动化工作流 + 定制Agent │
|
||||
├────────────┼──────────────────────────────────────────────────┤
|
||||
│ 竞品对比 │ Coze/Dify 的轻量替代，优势在飞书集成和工作流深度 │
|
||||
├────────────┼──────────────────────────────────────────────────┤
|
||||
│ 许可证 │ 无开源协议(私有项目) │
|
||||
├────────────┼──────────────────────────────────────────────────┤
|
||||
│ 部署方案 │ Docker Compose 一键部署，生产配置就绪 │
|
||||
├────────────┼──────────────────────────────────────────────────┤
|
||||
│ 安全成熟度 │ ⚠️ 刚修复35个安全/功能缺陷，仍需持续加固 │
|
||||
├────────────┼──────────────────────────────────────────────────┤
|
||||
│ 测试覆盖 │ 仅 10 个测试文件，覆盖严重不足 │
|
||||
└────────────┴──────────────────────────────────────────────────┘
|
||||
|
||||
---
|
||||
五、核心优势总结
|
||||
|
||||
1. Agent 运行时成熟度高 — ReAct循环+工具调用+自审查+预算控制，超过多数开源方案
|
||||
2. 飞书生态深度绑定 — 6个Bot独立运行，是中国企业场景的杀手级功能
|
||||
3. 工作流引擎功能完整 — 节点类型丰富，模板变量+条件分支+审批回路
|
||||
4. 全栈自研可控 — 无第三方低代码平台依赖，技术栈统一
|
||||
|
||||
六、关键短板
|
||||
|
||||
1. 测试几乎为零 — 10万行代码仅10个测试文件，生产风险高
|
||||
2. 安全债务重 — 35个已修复缺陷表明此前安全实践薄弱
|
||||
3. 单点故障风险 — 工作流引擎 6,188 行单体文件，维护成本高
|
||||
4. 数字孪生/知识进化 — 概念超前但实现浅，需持续投入
|
||||
|
||||
---
|
||||
七、总体估值
|
||||
|
||||
┌──────────────┬──────────────────────────────────────────┐
|
||||
│ 维度 │ 等级 │
|
||||
├──────────────┼──────────────────────────────────────────┤
|
||||
│ 技术成熟度 │ B+ (可运行但需加固) │
|
||||
├──────────────┼──────────────────────────────────────────┤
|
||||
│ 商业就绪度 │ B (功能全但缺测试和合规) │
|
||||
├──────────────┼──────────────────────────────────────────┤
|
||||
│ 创新性 │ A- (Agent编排+飞书集成有差异化) │
|
||||
├──────────────┼──────────────────────────────────────────┤
|
||||
│ 代码资产价值 │ 50-80万人天 (按全栈工程师 2000元/天估算) │
|
||||
└──────────────┴──────────────────────────────────────────┘
|
||||
|
||||
一句话: 这是一个有真实商业场景、架构设计合理、功能深度突出的 AI Agent
|
||||
平台，核心引擎价值高，但需要补齐测试、安全和监控才能进入生产级商业化阶段。
|
||||
|
||||
✻ Sautéed for 4m 28s · 2 background tasks still running
|
||||
|
||||
● Agent "项目价值评估调研" completed
|
||||
|
||||
● 后台调研完成，整合为最终评估报告。
|
||||
|
||||
---
|
||||
天工智能体平台 — 项目价值评估报告
|
||||
|
||||
一、规模概览
|
||||
|
||||
┌────────────┬──────────────────────────────────┐
|
||||
│ 指标 │ 数值 │
|
||||
├────────────┼──────────────────────────────────┤
|
||||
│ 后端代码 │ ~82,000 行 Python，273 个文件 │
|
||||
├────────────┼──────────────────────────────────┤
|
||||
│ 前端代码 │ ~31,000 行 Vue/TS，49 个页面组件 │
|
||||
├────────────┼──────────────────────────────────┤
|
||||
│ 数据库模型 │ 32 个 │
|
||||
├────────────┼──────────────────────────────────┤
|
||||
│ API 端点 │ ~250 个（33 个路由文件） │
|
||||
├────────────┼──────────────────────────────────┤
|
||||
│ 内置工具 │ 54 个 async 工具函数 │
|
||||
├────────────┼──────────────────────────────────┤
|
||||
│ 工作流引擎 │ 6,188 行 单体核心 │
|
||||
├────────────┼──────────────────────────────────┤
|
||||
│ 前端页面 │ 26 个（全部需认证） │
|
||||
├────────────┼──────────────────────────────────┤
|
||||
│ 总代码量 │ ~11 万行 │
|
||||
└────────────┴──────────────────────────────────┘
|
||||
|
||||
---
|
||||
二、技术栈
|
||||
|
||||
┌──────────┬───────────────────────────────────────────────────────────────────────────────┐
|
||||
│ 层 │ 技术 │
|
||||
├──────────┼───────────────────────────────────────────────────────────────────────────────┤
|
||||
│ 前端 │ Vue 3.4 + TypeScript + Vite + Pinia + Element Plus + Monaco Editor + Vue Flow │
|
||||
├──────────┼───────────────────────────────────────────────────────────────────────────────┤
|
||||
│ 后端 │ FastAPI + SQLAlchemy + Celery + Redis + Pydantic │
|
||||
├──────────┼───────────────────────────────────────────────────────────────────────────────┤
|
||||
│ AI │ LangChain + OpenAI / DeepSeek / SiliconFlow / Anthropic │
|
||||
├──────────┼───────────────────────────────────────────────────────────────────────────────┤
|
||||
│ 基础设施 │ Docker Compose + Nginx + MySQL + Prometheus + Filebeat │
|
||||
├──────────┼───────────────────────────────────────────────────────────────────────────────┤
|
||||
│ 集成 │ 飞书 6 套独立应用 + RabbitMQ + Kafka │
|
||||
└──────────┴───────────────────────────────────────────────────────────────────────────────┘
|
||||
|
||||
---
|
||||
三、架构亮点（核心竞争力）
|
||||
|
||||
┌──────────────────────┬────────┬──────────────────────────────────────────────────┐
|
||||
│ 能力 │ 成熟度 │ 说明 │
|
||||
├──────────────────────┼────────┼──────────────────────────────────────────────────┤
|
||||
│ Agent ReAct 自主循环 │ ★★★★★ │ 标准 LLM→工具→结果→反思 闭环，含预算熔断+自审查 │
|
||||
├──────────────────────┼────────┼──────────────────────────────────────────────────┤
|
||||
│ 可视化工作流 DAG │ ★★★★☆ │ 6K行引擎，支持 LLM/代码/HTTP/审批/条件/循环节点 │
|
||||
├──────────────────────┼────────┼──────────────────────────────────────────────────┤
|
||||
│ 多 Agent 编排 │ ★★★★☆ │ 串行/辩论/路由/流水线 4 种模式，Agent 间知识共享 │
|
||||
├──────────────────────┼────────┼──────────────────────────────────────────────────┤
|
||||
│ 飞书深度集成 │ ★★★★★ │ 6 个独立 Bot + WebSocket 直连，国内场景杀手级 │
|
||||
├──────────────────────┼────────┼──────────────────────────────────────────────────┤
|
||||
│ 知识体系 │ ★★★☆☆ │ RAG + 向量记忆 + 知识图谱 + 自动提取，刚完成基础 │
|
||||
├──────────────────────┼────────┼──────────────────────────────────────────────────┤
|
||||
│ 数字孪生/影子执行 │ ★★☆☆☆ │ 概念创新，实现较薄 │
|
||||
├──────────────────────┼────────┼──────────────────────────────────────────────────┤
|
||||
│ 行为采集+用户指纹 │ ★★★☆☆ │ 中间件+浏览器指纹，但反馈学习链路未闭合 │
|
||||
└──────────────────────┴────────┴──────────────────────────────────────────────────┘
|
||||
|
||||
---
|
||||
四、功能矩阵
|
||||
|
||||
Agent管理 ████████████ 创建/配置/设计/对话/市场
|
||||
工作流 ████████████ 可视化DAG/模板市场/执行历史
|
||||
工具生态 ██████████ 54内置+插件市场+HTTP/代码段
|
||||
多Agent编排 ██████████ 4种协作模式+编排模板
|
||||
飞书集成 ████████████ 6Bot+消息/文档/审批/日历
|
||||
调度告警 ██████████ Cron定时+告警规则+监控面板
|
||||
知识管理 ████████ RAG检索+图谱+自动学习
|
||||
数字员工 ██████ 数字孪生+员工工厂
|
||||
安全权限 ██████ JWT+角色+审批(刚加固)
|
||||
测试运维 ████ Docker+Prometheus+10测试文件
|
||||
|
||||
---
|
||||
五、商业化评估
|
||||
|
||||
┌────────────┬─────────────────────────────────┐
|
||||
│ 因素 │ 判断 │
|
||||
├────────────┼─────────────────────────────────┤
|
||||
│ 许可证 │ MIT 开源 │
|
||||
├────────────┼─────────────────────────────────┤
|
||||
│ 目标市场 │ 企业 AI 自动化 + 飞书生态用户 │
|
||||
├────────────┼─────────────────────────────────┤
|
||||
│ 竞品对标 │ Dify / Coze 的飞书特化替代方案 │
|
||||
├────────────┼─────────────────────────────────┤
|
||||
│ 部署就绪度 │ Docker 一键部署，生产配置齐全 │
|
||||
├────────────┼─────────────────────────────────┤
|
||||
│ 安全成熟度 │ ⚠️ 刚修复 35 个缺陷，需持续加固 │
|
||||
├────────────┼─────────────────────────────────┤
|
||||
│ 测试覆盖 │ ⚠️ 仅 10 个测试文件，严重不足 │
|
||||
├────────────┼─────────────────────────────────┤
|
||||
│ 文档完善度 │ ★★★★★ 8 篇文档 │
|
||||
└────────────┴─────────────────────────────────┘
|
||||
|
||||
---
|
||||
六、总体评估
|
||||
|
||||
┌──────────────┬────────────────────────────────┐
|
||||
│ 维度 │ 评级 │
|
||||
├──────────────┼────────────────────────────────┤
|
||||
│ 技术创新性 │ A- │
|
||||
├──────────────┼────────────────────────────────┤
|
||||
│ 架构完整性 │ B+ │
|
||||
├──────────────┼────────────────────────────────┤
|
||||
│ 代码质量 │ B- │
|
||||
├──────────────┼────────────────────────────────┤
|
||||
│ 商业就绪度 │ B │
|
||||
├──────────────┼────────────────────────────────┤
|
||||
│ 代码资产估值 │ 50-80 万元（按全栈 2000元/天） │
|
||||
└──────────────┴────────────────────────────────┘
|
||||
|
||||
结论: 这是一个有真实商业场景、架构合理、飞书集成深度突出的 AI Agent 平台。核心引擎（Agent Runtime + 工作流引擎 +
|
||||
多Agent编排）价值高，但需补齐测试、安全加固和监控才能进入生产级 SaaS 阶段。最突出的差异化优势是飞书 6 Bot
|
||||
深度集成，在国内企业协同场景有明确竞争力。
|
||||
12
docs/Obsidian笔记体系/Projects/agent/飞书机器人.md
Normal file
12
docs/Obsidian笔记体系/Projects/agent/飞书机器人.md
Normal file
@@ -0,0 +1,12 @@
|
||||
苹果
|
||||
appid cli_a97f3e2ecaf81cba
|
||||
Verification Token
|
||||
6BtaWwXqQZh29syLvdxstcS8tIGMmI8U
|
||||
|
||||
App Secret KtS5Df3qk9mLrZTJuU2NDgNyv1DFacsE
|
||||
|
||||
橙子
|
||||
appid cli_a97f1271ec345cc6
|
||||
App Secret FrGxzzvZazeRbfpYvQbo5dZEiYXz84BF
|
||||
Verification Token
|
||||
FpLhWw4gmSHKO1Wx9AQcGc0YKFCP5qc1
|
||||
@@ -0,0 +1,241 @@
|
||||
|
||||
aitsc 是一个功能完整、架构清晰的 AI 提示词生成平台，具备以下优势：
|
||||
|
||||
1. 产品定位准确：抓住 AI 提示词优化市场痛点
|
||||
2. 技术栈合理：Python/Flask 生态成熟稳定
|
||||
3. 功能覆盖全面：从核心提示词生成到多场景 AI 应用
|
||||
4. 部署方案完备：支持从开发到生产的全链路部署
|
||||
|
||||
主要风险集中在安全方面：硬编码的数据库密码和 API 密钥一旦泄露，可能导致数据泄露和 API
|
||||
滥用。建议优先解决此问题后再投入生产使用。
|
||||
|
||||
项目具备良好的商业化潜力，只需进行适当的安全加固和架构优化，即可成为成熟的 AI 应用平台。
|
||||
|
||||
---分析完成时间：2026-04-02
|
||||
分析工具：Claude Code (Sonnet 4.6)
|
||||
|
||||
● aitsc 项目分析报告
|
||||
|
||||
项目概述
|
||||
|
||||
项目名称：提示词大师 (aitsc / flask_prompt_master)
|
||||
项目定位：基于大语言模型（LLM）的智能提示词生成与多场景 AI 应用平台
|
||||
技术栈：Python 3.12、Flask、Gunicorn、SQLAlchemy、MySQL、DeepSeek API（OpenAI 兼容）、Docker、Kubernetes
|
||||
目标用户：Web 用户、微信小程序用户、管理员
|
||||
部署方式：本地开发、Docker 容器化、K8s 云部署、Windows 服务
|
||||
访问端口：5002
|
||||
|
||||
项目结构分析
|
||||
|
||||
目录结构
|
||||
|
||||
aitsc/
|
||||
├── src/flask_prompt_master/ # 主应用核心
|
||||
│ ├── __init__.py # 应用工厂函数
|
||||
│ ├── app.py # 模拟 API 服务（测试用）
|
||||
│ ├── config.py # 应用配置
|
||||
│ ├── models/ # 数据模型
|
||||
│ │ ├── models.py # 核心数据模型
|
||||
│ │ ├── favorites.py # 收藏模型
|
||||
│ │ ├── history_models.py # 历史记录模型
|
||||
│ │ ├── optimization_history.py # 优化历史模型
|
||||
│ │ └── poetry_favorites.py # 古诗词收藏模型
|
||||
│ ├── routes/ # 业务路由（蓝图）
|
||||
│ │ ├── routes.py # 主路由
|
||||
│ │ ├── auth.py # 认证路由
|
||||
│ │ ├── favorites.py # 收藏路由
|
||||
│ │ ├── meal_planning.py # 饭菜规划路由
|
||||
│ │ ├── poetry.py # 古诗词解析路由
|
||||
│ │ ├── history_routes.py # 历史记录路由
|
||||
│ │ ├── weekly_report.py # 智能周报路由
|
||||
│ │ ├── travel_planning.py # 旅行攻略路由
|
||||
│ │ ├── meeting_minutes.py # 会议纪要多路由
|
||||
│ │ ├── resume_optimization.py # 简历优化路由
|
||||
│ │ ├── prompt_optimization.py # 提示词优化路由
|
||||
│ │ ├── smart_prompt_optimization.py # 智能提示词优化路由
|
||||
│ │ ├── expert_generate_2.py # 专家提示词2号
|
||||
│ │ ├── expert_generate_3.py # 专家提示词3号
|
||||
│ │ ├── android_tools.py # Android 工程师工具
|
||||
│ │ └── placeholder_apps.py # 占位应用
|
||||
│ ├── services/ # 业务逻辑服务
|
||||
│ │ ├── auth_service.py # 认证服务
|
||||
│ │ ├── favorite_service.py # 收藏服务
|
||||
│ │ └── poetry_favorite_service.py # 古诗词收藏服务
|
||||
│ ├── forms/ # 表单类（待完善）
|
||||
│ ├── templates/ # HTML 模板
|
||||
│ ├── static/ # 静态资源
|
||||
│ ├── utils/ # 工具函数
|
||||
│ ├── admin/ # 后台管理
|
||||
│ └── promptsTemplates.py # 提示词模板数据（144KB）
|
||||
├── config.py # 全局配置（含腾讯云数据库）
|
||||
├── docker-compose.yml # Docker Compose 配置
|
||||
├── docker-compose.prod.yml # 生产环境配置
|
||||
├── docker-compose.simple.yml # 简化配置
|
||||
├── Dockerfile # 应用 Dockerfile
|
||||
├── Dockerfile.log-manager # 日志管理 Dockerfile
|
||||
├── Dockerfile.monitor # 监控 Dockerfile
|
||||
├── requirements.txt # Python 依赖
|
||||
├── run_dev.py # 开发环境启动脚本
|
||||
├── run_dev_fixed.py # 修复版启动脚本
|
||||
├── run_production_public.py # 生产环境启动脚本
|
||||
├── k8s/ # Kubernetes 配置
|
||||
├── wechat-miniprogram/ # 微信小程序代码
|
||||
├── exampleAiApp01/ # 示例 AI 应用
|
||||
├── scripts/ # 部署和管理脚本
|
||||
├── tests/ # 测试文件
|
||||
├── migrations/ # 数据库迁移
|
||||
├── logs/ # 日志目录
|
||||
├── docs/ # 文档
|
||||
├── backups/ # 备份文件
|
||||
└── 大量中文文档（功能设计、部署指南、优化报告等）
|
||||
|
||||
架构设计
|
||||
|
||||
- MVC 模式：清晰的数据模型（Model）、视图模板（View）、路由控制器（Controller）
|
||||
- 蓝图模块化：功能按业务模块划分，便于维护和扩展
|
||||
- 服务层分离：业务逻辑集中在 services 目录，路由层保持简洁
|
||||
- 配置管理：支持多环境配置（开发、测试、生产）
|
||||
- 数据库：MySQL + SQLAlchemy ORM，支持本地和腾讯云双数据库
|
||||
|
||||
功能模块分析
|
||||
|
||||
1. 核心 AI 功能
|
||||
|
||||
- 提示词生成：用户输入简短描述，基于模板调用 LLM 生成高质量提示词
|
||||
- 意图识别：分析用户输入，推荐模板类别（新闻获取、生成图片、网站开发等）
|
||||
- 专家提示词：两阶段生成（意图分析 → 领域专家模板生成）
|
||||
|
||||
2. 多场景 AI 应用
|
||||
|
||||
- 智能饭菜规划：根据人数、餐型、家乡、预算等生成地区化饭菜清单
|
||||
- 古诗词解析：提供原文、译文、注释、解读（支持收藏功能）
|
||||
- 智能周报/日报：根据工作要点生成结构化报告
|
||||
- 旅行攻略规划：基于目的地、天数、人数、预算生成详细攻略
|
||||
- 会议纪要整理：原始内容转写为结构化纪要
|
||||
- 简历/求职信优化：根据岗位描述针对性优化简历内容
|
||||
- Android 工程师工具：Crash 解读、依赖冲突分析等专业工具
|
||||
|
||||
3. 用户系统
|
||||
|
||||
- Web 用户认证：注册、登录、个人资料、Session 管理
|
||||
- 微信小程序登录：code 换 openid/session_key，返回自定义 uid
|
||||
- 权限控制：登录验证装饰器保护敏感接口
|
||||
|
||||
4. 数据管理
|
||||
|
||||
- 收藏功能：通用收藏管理，支持增删改查、统计
|
||||
- 历史记录：提示词历史、优化历史的查看、标签、批量操作
|
||||
- 模板管理：内置行业模板（写作、故事、短视频、设计、营销等）
|
||||
|
||||
5. 管理功能
|
||||
|
||||
- Flask-Admin 后台：用户/内容/系统/数据分析管理
|
||||
- 监控服务：系统运行状态监控
|
||||
- 日志管理：集中式日志收集和分析
|
||||
|
||||
代码质量分析
|
||||
|
||||
优点
|
||||
|
||||
1. 结构清晰：符合 Flask 最佳实践，模块划分合理
|
||||
2. 文档完善：大量中文文档覆盖功能设计、部署指南、优化报告
|
||||
3. 部署方案全面：支持 Docker、K8s、Windows 服务多种部署方式
|
||||
4. 测试覆盖：包含大量测试文件，覆盖主要功能
|
||||
5. 错误处理：全局 500 错误处理，记录完整堆栈信息
|
||||
|
||||
安全问题
|
||||
|
||||
硬编码敏感信息（高风险）：
|
||||
- 数据库密码：!Rjb12191（腾讯云数据库）
|
||||
- DeepSeek API 密钥：sk-fdf7cc1c73504e628ec0119b7e11b8cc
|
||||
- 微信小程序密钥：89aa97dda3c1347c6ae3d6ab4627f1f4
|
||||
- 位置：config.py 和 src/flask_prompt_master/config.py
|
||||
密码哈希安全性不足：
|
||||
- 使用 MD5 加盐哈希，建议升级为 bcrypt 或 Argon2
|
||||
- 位置：auth_service.py 的 hash_password 方法
|
||||
CORS 配置过于宽松：
|
||||
- CORS_ORIGINS = ['*'] 生产环境应限制具体域名
|
||||
|
||||
代码规范问题
|
||||
|
||||
6. 配置文件重复：根目录和 src/flask_prompt_master 下都有 config.py
|
||||
7. 大型数据文件：promptsTemplates.py 文件过大（144KB），应考虑数据库存储
|
||||
8. 模拟数据与真实代码混合：app.py 包含模拟 API，可能与真实路由混淆
|
||||
9. 中英混合命名：部分文件和变量使用中文，不利于国际化协作
|
||||
|
||||
依赖管理
|
||||
|
||||
- 主要依赖：Flask、SQLAlchemy、OpenAI、PyMySQL、Redis 等
|
||||
- 版本管理：requirements.txt 指定版本范围，但缺少 lock 文件
|
||||
- Windows 特定依赖：pywin32 用于 Windows 服务部署
|
||||
|
||||
部署与运维
|
||||
|
||||
支持的部署方式
|
||||
|
||||
1. 本地开发：Python 虚拟环境 + Flask 开发服务器
|
||||
2. Docker 容器化：完整微服务栈（App + MySQL + Redis + Nginx）
|
||||
3. Kubernetes：生产级容器编排配置
|
||||
4. Windows 服务：通过 pywin32 部署为系统服务
|
||||
5. 腾讯云集成：支持腾讯云数据库直连
|
||||
|
||||
监控与维护
|
||||
|
||||
- 日志管理：Docker 日志卷 + 独立日志管理服务
|
||||
- 系统监控：独立的监控服务和管理器
|
||||
- 数据库迁移：Flask-Migrate 支持数据库版本管理
|
||||
- 备份机制：定期备份目录和脚本
|
||||
|
||||
改进建议
|
||||
|
||||
高优先级
|
||||
|
||||
修复安全漏洞：
|
||||
- 移除硬编码的敏感信息，全部改为环境变量
|
||||
- 更新密码哈希算法为 bcrypt 或 Argon2
|
||||
- 生产环境限制 CORS 域名
|
||||
配置文件优化：
|
||||
- 统一配置管理，消除重复配置
|
||||
- 实现多环境配置自动切换
|
||||
|
||||
中优先级
|
||||
|
||||
代码重构：
|
||||
- 将 promptsTemplates.py 大文件内容迁移到数据库
|
||||
- 清理测试和模拟代码，分离测试环境
|
||||
- 统一命名规范，减少中英混合
|
||||
依赖管理：
|
||||
- 添加 requirements.lock 文件确保依赖一致性
|
||||
- 考虑使用 Poetry 或 Pipenv 管理依赖
|
||||
API 设计：
|
||||
- 统一 API 响应格式和错误码
|
||||
- 添加 API 版本控制（目前部分使用 /api/v1/，部分没有）
|
||||
|
||||
低优先级
|
||||
|
||||
性能优化：
|
||||
- 考虑添加 Redis 缓存层减少数据库压力
|
||||
- 优化大型查询的分页性能
|
||||
文档完善：
|
||||
- 添加 API 接口文档（OpenAPI/Swagger）
|
||||
- 补充部署环境的详细配置说明
|
||||
测试增强：
|
||||
- 增加集成测试和端到端测试
|
||||
- 添加 CI/CD 流水线自动化测试
|
||||
|
||||
总结
|
||||
|
||||
aitsc 项目是一个功能丰富、架构清晰的 AI 应用平台，具备以下特点：
|
||||
|
||||
优势：
|
||||
- 功能全面，覆盖多场景 AI 应用需求
|
||||
- 架构设计合理，模块化程度高
|
||||
- 部署方案多样，适应不同环境需求
|
||||
- 文档完善，便于理解和维护
|
||||
|
||||
风险：
|
||||
- 安全漏洞较为严重（硬编码敏感信息）
|
||||
- 部分代码需要重构优化
|
||||
- 生产环境配置需要加固
|
||||
|
||||
建议：立即修复安全漏洞，然后进行代码重构和性能优化，可发展为成熟的企业级 AI 应用平台。
|
||||
126
docs/Obsidian笔记体系/Projects/aitsc/wk1.md
Normal file
126
docs/Obsidian笔记体系/Projects/aitsc/wk1.md
Normal file
@@ -0,0 +1,126 @@
|
||||
● 高优先级安全改进状态分析
|
||||
|
||||
基于对 aitsc 项目的检查，以下是高优先级安全改进的完成情况：
|
||||
|
||||
✅ 已完成的安全改进
|
||||
|
||||
新的配置系统已实现
|
||||
- 创建了 config/ 目录，包含 base.py、development.py、production.py、testing.py
|
||||
- 根目录和 src/flask_prompt_master/config.py 都添加了弃用警告
|
||||
- 新配置系统强制从环境变量读取敏感信息，否则抛出异常
|
||||
密码哈希算法已升级
|
||||
- auth_service.py 中已使用 bcrypt 哈希算法
|
||||
- 支持向后兼容 MD5（用于现有用户）
|
||||
- 新用户注册使用 bcrypt，安全性达标
|
||||
生产环境 CORS 配置已加固
|
||||
- production.py 中强制要求设置 CORS_ORIGINS 环境变量
|
||||
- 生产环境不能使用 ['*']，必须指定具体域名
|
||||
|
||||
⚠️ 仍需解决的安全问题
|
||||
|
||||
.env 文件中仍包含硬编码敏感信息
|
||||
- 数据库密码：!Rjb12191
|
||||
- DeepSeek API 密钥：sk-fdf7cc1c73504e628ec0119b7e11b8cc
|
||||
- 微信小程序密钥：89aa97dda3c1347c6ae3d6ab4627f1f4
|
||||
源代码中仍有多处硬编码
|
||||
- promptsTemplates.py 中硬编码数据库密码
|
||||
- 多个路由文件（如 android_tools.py）硬编码 API 密钥作为后备值
|
||||
- 多个部署脚本和文档文件包含敏感信息
|
||||
.env 文件管理问题
|
||||
- .env 文件不应提交到版本控制
|
||||
- 应使用 .env.example 作为模板，要求用户手动创建 .env
|
||||
|
||||
🔍 发现的具体文件
|
||||
|
||||
通过搜索发现的硬编码敏感信息文件：
|
||||
- .env 文件（包含完整的敏感信息）
|
||||
- src/flask_prompt_master/promptsTemplates.py（第4098、4108行有数据库密码）
|
||||
- 多个路由文件使用 os.environ.get('LLM_API_KEY') or 'sk-fdf7cc1c73504e628ec0119b7e11b8cc' 模式
|
||||
- 大量文档和部署脚本文件包含敏感信息
|
||||
|
||||
📋 建议的下一步修复
|
||||
|
||||
立即移除 .env 中的硬编码信息
|
||||
- 使用占位符替换真实密钥
|
||||
- 添加更详细的说明要求用户从控制台获取真实密钥
|
||||
清理源代码中的硬编码后备值
|
||||
- 移除所有 or 'hardcoded-key' 模式的后备值
|
||||
- 如果环境变量未设置，应抛出自定义异常而非使用默认值
|
||||
加强 .env 文件管理
|
||||
- 将 .env 添加到 .gitignore
|
||||
- 完善 .env.example 说明文档
|
||||
|
||||
虽然配置架构已改进，但只要源代码和 .env 文件中还存在硬编码敏感信息，安全风险就仍然存在。
|
||||
|
||||
● 根据分析，aitsc项目的高优先级安全改进已经部分完成。具体状态如下：
|
||||
|
||||
✅ 已解决的改进
|
||||
|
||||
配置系统重构
|
||||
- 新的配置系统位于 config/ 目录，支持多环境配置
|
||||
- 根目录 config.py 和 src/flask_prompt_master/config.py 已添加弃用警告
|
||||
- 强制从环境变量读取敏感信息，未设置时会抛出 ValueError
|
||||
密码哈希安全性升级
|
||||
- auth_service.py 已实现 bcrypt 哈希算法
|
||||
- 支持向后兼容 MD5（旧用户）
|
||||
- 新用户默认使用 bcrypt，盐值标识为 'bcrypt'
|
||||
生产环境 CORS 配置加固
|
||||
- config/production.py 中强制要求设置 CORS_ORIGINS 环境变量
|
||||
- 未设置或为空时会抛出异常
|
||||
|
||||
⚠️ 仍需解决的严重问题
|
||||
|
||||
1. 源代码中的硬编码敏感信息
|
||||
|
||||
多个Python文件中仍存在硬编码的敏感信息：
|
||||
|
||||
数据库密码 (!Rjb12191):
|
||||
- src/flask_prompt_master/promptsTemplates.py (4098行)
|
||||
- 至少10个其他脚本文件（部署、初始化脚本）
|
||||
DeepSeek API 密钥 (sk-fdf7cc1c73504e628ec0119b7e11b8cc):
|
||||
- src/flask_prompt_master/routes/android_tools.py (17行)
|
||||
- src/flask_prompt_master/routes/expert_generate_2.py
|
||||
- src/flask_prompt_master/routes/expert_generate_3.py
|
||||
- src/flask_prompt_master/routes/meal_planning.py (仍有硬编码)
|
||||
- 多个其他路由文件
|
||||
微信小程序密钥 (89aa97dda3c1347c6ae3d6ab4627f1f4):
|
||||
- 在 .env 文件和其他文档中
|
||||
|
||||
2. .env 文件中的硬编码
|
||||
|
||||
.env 文件仍然包含：
|
||||
- DATABASE_URL 中的数据库密码
|
||||
- LLM_API_KEY (DeepSeek API密钥)
|
||||
- WX_APPID 和 WX_SECRET (微信小程序凭据)
|
||||
|
||||
风险：.env 文件可能被意外提交到版本控制，导致敏感信息泄露。
|
||||
|
||||
3. 配置文件重复问题
|
||||
|
||||
虽然有了新的 config/ 系统，但两个旧配置文件的弃用警告仍不够彻底：
|
||||
- config.py (根目录)
|
||||
- src/flask_prompt_master/config.py
|
||||
|
||||
🔍 遗留的中优先级问题
|
||||
|
||||
大型数据文件 promptsTemplates.py (144KB)
|
||||
- 仍包含硬编码的数据库连接信息
|
||||
- 应考虑迁移到数据库存储
|
||||
API密钥使用不一致
|
||||
- 有些路由文件使用 os.environ.get('LLM_API_KEY') or '硬编码密钥' 模式
|
||||
- 应统一为强制从环境变量读取，去掉 fallback 硬编码
|
||||
|
||||
📋 建议的后续行动
|
||||
|
||||
立即行动（高优先级）：
|
||||
1. 清理所有源代码中的硬编码敏感信息
|
||||
2. 将 .env 中的真实凭据替换为占位符
|
||||
3. 确保 .env 在 .gitignore 中，只提交 .env.example
|
||||
4. 更新所有路由文件，移除 API 密钥的硬编码 fallback
|
||||
|
||||
近期行动（中优先级）：
|
||||
1. 将 promptsTemplates.py 的大数据迁移到数据库
|
||||
2. 完全移除旧的配置文件或重定向到新系统
|
||||
3. 统一 API 密钥获取逻辑
|
||||
|
||||
总结：配置架构已改进，但代码层面仍有严重的安全漏洞需要立即修复，否则新的配置系统无法提供实际安全保护。
|
||||
227
docs/Obsidian笔记体系/Projects/aitsc/wk2.md
Normal file
227
docs/Obsidian笔记体系/Projects/aitsc/wk2.md
Normal file
@@ -0,0 +1,227 @@
|
||||
● 根据分析，promptsTemplates.py 的数据迁移确实是一个重要的中优先级改进。以下是详细的迁移方案和实施步骤：
|
||||
|
||||
📊 当前问题分析
|
||||
|
||||
promptsTemplates.py 的主要问题：
|
||||
|
||||
1. 安全漏洞：包含硬编码数据库密码（腾讯云：!Rjb12191，本地：123456）
|
||||
2. 数据与代码混合：144KB 文件中约 4000 行是模板数据
|
||||
3. 不规范的数据库连接：使用 pymysql 直接连接，而不是项目的 SQLAlchemy ORM
|
||||
4. 冗余功能：既是数据存储又是初始化脚本
|
||||
|
||||
✅ 有利条件：
|
||||
|
||||
- 应用已通过 PromptTemplate.query 从数据库获取模板
|
||||
- PromptTemplate 模型已在 models.py 中定义
|
||||
- 项目已有完整的数据库迁移系统 (migrations/ 目录)
|
||||
- 新的配置系统已就位
|
||||
|
||||
🎯 迁移实施计划
|
||||
|
||||
阶段一：数据提取和备份（30分钟）
|
||||
|
||||
1. 提取模板数据到 JSON
|
||||
# 创建数据目录
|
||||
mkdir -p /d/aaa/aitsc/data
|
||||
|
||||
# 手动或编写脚本提取 templates 列表到 JSON
|
||||
# 将生成：data/prompt_templates.json
|
||||
|
||||
2. 备份现有数据库中的模板数据
|
||||
# 创建备份脚本
|
||||
from src.flask_prompt_master import create_app, db
|
||||
from src.flask_prompt_master.models.models import PromptTemplate
|
||||
import json
|
||||
|
||||
app = create_app()
|
||||
with app.app_context():
|
||||
templates = PromptTemplate.query.all()
|
||||
data = [{
|
||||
'name': t.name,
|
||||
'description': t.description,
|
||||
'category': t.category,
|
||||
'industry': t.industry,
|
||||
'profession': t.profession,
|
||||
'sub_category': t.sub_category,
|
||||
'system_prompt': t.system_prompt,
|
||||
'is_default': t.is_default
|
||||
} for t in templates]
|
||||
|
||||
with open('data/existing_templates_backup.json', 'w', encoding='utf-8') as f:
|
||||
json.dump(data, f, ensure_ascii=False, indent=2)
|
||||
|
||||
阶段二：创建安全初始化系统（45分钟）
|
||||
|
||||
1. 创建新的初始化脚本
|
||||
# scripts/init_prompt_templates.py
|
||||
import json
|
||||
import os
|
||||
from dotenv import load_dotenv
|
||||
from src.flask_prompt_master import create_app, db
|
||||
from src.flask_prompt_master.models.models import PromptTemplate
|
||||
|
||||
load_dotenv()
|
||||
|
||||
def init_from_json(json_file='data/prompt_templates.json'):
|
||||
"""从JSON文件安全初始化模板数据"""
|
||||
app = create_app()
|
||||
with app.app_context():
|
||||
# 检查数据库连接
|
||||
if not db.session.bind:
|
||||
raise ValueError("数据库连接未初始化")
|
||||
|
||||
# 加载模板数据
|
||||
with open(json_file, 'r', encoding='utf-8') as f:
|
||||
templates_data = json.load(f)
|
||||
|
||||
added_count = 0
|
||||
skipped_count = 0
|
||||
|
||||
for template_data in templates_data:
|
||||
# 检查是否已存在同名模板
|
||||
existing = PromptTemplate.query.filter_by(
|
||||
name=template_data['name']
|
||||
).first()
|
||||
|
||||
if not existing:
|
||||
template = PromptTemplate(**template_data)
|
||||
db.session.add(template)
|
||||
added_count += 1
|
||||
else:
|
||||
skipped_count += 1
|
||||
|
||||
try:
|
||||
db.session.commit()
|
||||
print(f"✅ 初始化完成：新增 {added_count} 条，跳过 {skipped_count} 条")
|
||||
return True
|
||||
except Exception as e:
|
||||
db.session.rollback()
|
||||
print(f"❌ 初始化失败：{e}")
|
||||
return False
|
||||
|
||||
if __name__ == '__main__':
|
||||
init_from_json()
|
||||
|
||||
2. 更新 promptsTemplates.py（保留向后兼容）
|
||||
# 在 promptsTemplates.py 顶部添加
|
||||
import warnings
|
||||
warnings.warn(
|
||||
"promptsTemplates.py 已弃用，请使用 scripts/init_prompt_templates.py",
|
||||
DeprecationWarning
|
||||
)
|
||||
|
||||
# 修改 init_db 函数，移除硬编码密码，调用新的初始化脚本
|
||||
def init_db(database_type='local'):
|
||||
"""向后兼容的初始化函数（重定向到新系统）"""
|
||||
print("⚠️ 此函数已弃用，请使用新的初始化系统")
|
||||
print("💡 运行: python scripts/init_prompt_templates.py")
|
||||
# 或者直接调用新脚本
|
||||
from scripts.init_prompt_templates import init_from_json
|
||||
return init_from_json()
|
||||
|
||||
阶段三：环境配置和安全加固（30分钟）
|
||||
|
||||
1. 更新 .env.example 文件
|
||||
# 移除真实凭据，使用占位符
|
||||
DATABASE_URL=mysql+pymysql://username:password@host:port/database_name?charset=utf8mb4
|
||||
LLM_API_KEY=sk-your-api-key-here
|
||||
WX_SECRET=your-wx-secret-here
|
||||
|
||||
2. 确保 .env 不被提交
|
||||
# 检查 .gitignore
|
||||
echo ".env" >> /d/aaa/aitsc/.gitignore
|
||||
echo ".env.*" >> /d/aaa/aitsc/.gitignore
|
||||
echo "!*.example" >> /d/aaa/aitsc/.gitignore
|
||||
|
||||
3. 创建部署说明文档
|
||||
# 模板数据初始化说明
|
||||
|
||||
## 新系统使用
|
||||
4. 复制环境变量模板：`cp .env.example .env`
|
||||
5. 编辑 .env 文件，填入真实凭据
|
||||
6. 初始化模板数据：`python scripts/init_prompt_templates.py`
|
||||
|
||||
## 旧系统兼容
|
||||
旧命令 `python src/flask_prompt_master/promptsTemplates.py [local|tencent]`
|
||||
将自动重定向到新系统。
|
||||
|
||||
阶段四：测试和验证（30分钟）
|
||||
|
||||
7. 测试脚本
|
||||
# tests/test_template_init.py
|
||||
import pytest
|
||||
from scripts.init_prompt_templates import init_from_json
|
||||
from src.flask_prompt_master.models.models import PromptTemplate
|
||||
|
||||
def test_template_count():
|
||||
"""测试模板数量是否正确"""
|
||||
init_from_json('tests/test_templates.json')
|
||||
count = PromptTemplate.query.count()
|
||||
assert count > 0
|
||||
|
||||
def test_no_duplicates():
|
||||
"""测试不会创建重复模板"""
|
||||
init_from_json('tests/test_templates.json')
|
||||
count1 = PromptTemplate.query.count()
|
||||
init_from_json('tests/test_templates.json') # 再次运行
|
||||
count2 = PromptTemplate.query.count()
|
||||
assert count1 == count2 # 数量应不变
|
||||
|
||||
📅 实施时间表
|
||||
|
||||
┌──────┬────────────────┬──────────┬────────┐
|
||||
│ 阶段 │ 任务 │ 预计时间 │ 优先级 │
|
||||
├──────┼────────────────┼──────────┼────────┤
|
||||
│ 1 │ 数据提取和备份 │ 30分钟 │ 高 │
|
||||
├──────┼────────────────┼──────────┼────────┤
|
||||
│ 2 │ 安全初始化脚本 │ 45分钟 │ 高 │
|
||||
├──────┼────────────────┼──────────┼────────┤
|
||||
│ 3 │ 环境配置加固 │ 30分钟 │ 高 │
|
||||
├──────┼────────────────┼──────────┼────────┤
|
||||
│ 4 │ 测试验证 │ 30分钟 │ 中 │
|
||||
├──────┼────────────────┼──────────┼────────┤
|
||||
│ 5 │ 文档更新 │ 15分钟 │ 中 │
|
||||
├──────┼────────────────┼──────────┼────────┤
|
||||
│ 总计 │ │ 2.5小时 │ │
|
||||
└──────┴────────────────┴──────────┴────────┘
|
||||
|
||||
🔧 迁移后的架构
|
||||
|
||||
aitsc/
|
||||
├── data/ # 数据文件目录
|
||||
│ ├── prompt_templates.json # 模板数据（JSON格式）
|
||||
│ └── existing_templates_backup.json
|
||||
├── scripts/ # 管理脚本
|
||||
│ ├── init_prompt_templates.py # 安全初始化脚本
|
||||
│ └── backup_templates.py
|
||||
├── src/flask_prompt_master/
|
||||
│ └── promptsTemplates.py # 已弃用（保留兼容）
|
||||
└── .env.example # 环境变量模板
|
||||
|
||||
⚠️ 风险和缓解措施
|
||||
|
||||
风险: 生产数据库已有模板数据
|
||||
- 缓解: 初始化脚本检查重复，不会覆盖现有数据
|
||||
风险: 依赖旧初始化流程的脚本
|
||||
- 缓解: 保留 promptsTemplates.py 的兼容性包装
|
||||
风险: JSON 文件可能过大
|
||||
- 缓解: 可考虑分多个 JSON 文件或使用数据库种子
|
||||
|
||||
📝 下一步建议
|
||||
|
||||
立即行动:
|
||||
8. 先备份现有数据库中的模板数据
|
||||
9. 提取当前 promptsTemplates.py 中的模板到 JSON
|
||||
10. 创建安全初始化脚本
|
||||
|
||||
验证后:
|
||||
11. 在测试环境运行新系统
|
||||
12. 更新部署文档
|
||||
13. 全面替换旧系统
|
||||
|
||||
您希望我：
|
||||
14. 立即开始实施这个迁移方案？
|
||||
15. 先处理更高优先级的硬编码安全问题？
|
||||
16. 还是您有其他特定的要求？
|
||||
|
||||
迁移完成后，项目的安全性、可维护性和部署便利性将显著提升。
|
||||
151
docs/Obsidian笔记体系/Projects/aitsc/wk3 Windows 运行.md
Normal file
151
docs/Obsidian笔记体系/Projects/aitsc/wk3 Windows 运行.md
Normal file
@@ -0,0 +1,151 @@
|
||||
✅ 完全支持 Windows 运行
|
||||
|
||||
aitsc 项目完全支持在 Windows 系统上运行，并且提供了多种运行方式，从开发环境到生产部署都有完整支持。
|
||||
|
||||
🚀 支持的运行方式
|
||||
|
||||
1. 开发环境运行（最简单）
|
||||
|
||||
# 激活虚拟环境（推荐）
|
||||
.venv\Scripts\Activate.bat
|
||||
|
||||
# 启动开发服务器
|
||||
python run_dev.py
|
||||
- 访问地址：http://localhost:5002
|
||||
- 调试模式开启，代码修改自动重载
|
||||
|
||||
2. 生产环境运行
|
||||
|
||||
# 使用生产启动脚本
|
||||
start_production.bat
|
||||
# 或
|
||||
python run_production_public.py
|
||||
- 关闭调试模式，优化性能
|
||||
- 监听所有网络接口（支持外网访问）
|
||||
- 多线程处理请求
|
||||
|
||||
3. Windows 系统服务（推荐用于生产）
|
||||
|
||||
# 以管理员身份运行安装脚本
|
||||
install_service.bat
|
||||
|
||||
# 或手动安装服务
|
||||
python flask_prompt_master_service.py install
|
||||
python flask_prompt_master_service.py start
|
||||
- 支持开机自启动
|
||||
- 后台运行，无需保持命令行窗口
|
||||
- 作为系统服务管理（启动/停止/重启）
|
||||
|
||||
4. 简化版开机启动
|
||||
|
||||
# 使用任务计划程序实现开机启动
|
||||
python simple_windows_service.py install
|
||||
- 基于 Windows 任务计划程序
|
||||
- 系统启动时自动运行
|
||||
- 不需要完整服务框架
|
||||
|
||||
📋 Windows 运行前提条件
|
||||
|
||||
1. Python 环境
|
||||
|
||||
- Python 3.12（推荐）
|
||||
- 已安装 pip
|
||||
|
||||
2. 虚拟环境（推荐）
|
||||
|
||||
# 创建虚拟环境
|
||||
python -m venv .venv
|
||||
|
||||
# 激活虚拟环境
|
||||
.venv\Scripts\Activate.bat
|
||||
|
||||
3. 安装依赖
|
||||
|
||||
pip install -r requirements.txt
|
||||
关键 Windows 依赖：
|
||||
- pywin32 - Windows API 接口（服务部署必需）
|
||||
- waitress - WSGI 服务器
|
||||
- bcrypt - 密码哈希（已升级安全算法）
|
||||
|
||||
🔧 Windows 特定配置
|
||||
|
||||
1. 环境变量配置
|
||||
|
||||
- 复制 .env.example 为 .env
|
||||
- 编辑 .env 文件，配置数据库连接等参数
|
||||
- 注意：Windows 路径使用反斜杠或双反斜杠
|
||||
|
||||
2. 端口配置
|
||||
|
||||
- 默认端口：5002（开发）/ 5000（服务）
|
||||
- 如果端口冲突，可在 .env 中修改 PORT 变量
|
||||
|
||||
3. 防火墙配置
|
||||
|
||||
# 允许端口通过防火墙
|
||||
New-NetFirewallRule -DisplayName "FlaskPromptMaster" -Direction Inbound -LocalPort 5000 -Protocol TCP
|
||||
-Action Allow
|
||||
|
||||
📁 关键 Windows 文件
|
||||
|
||||
aitsc/
|
||||
├── install_service.bat # 服务安装脚本（管理员运行）
|
||||
├── install_startup.bat # 开机启动安装脚本
|
||||
├── service_manager.bat # 服务管理脚本（图形菜单）
|
||||
├── simple_service_manager.bat # 简化版服务管理
|
||||
├── start_production.bat # 生产环境启动脚本
|
||||
├── flask_prompt_master_service.py # 完整 Windows 服务脚本
|
||||
├── simple_windows_service.py # 简化版服务脚本
|
||||
└── docs/development/
|
||||
└── Windows服务配置总结.md # 详细配置指南
|
||||
|
||||
⚡ 快速开始指南
|
||||
|
||||
方案一：开发测试
|
||||
# 1. 安装依赖
|
||||
pip install -r requirements.txt
|
||||
|
||||
# 2. 配置环境变量
|
||||
copy .env.example .env
|
||||
# 编辑 .env 文件（数据库、API密钥等）
|
||||
|
||||
# 3. 启动开发服务器
|
||||
python run_dev.py
|
||||
|
||||
方案二：生产部署
|
||||
# 1. 安装依赖和服务组件
|
||||
pip install -r requirements.txt
|
||||
|
||||
# 2. 安装 Windows 服务
|
||||
install_service.bat
|
||||
# 或右键"以管理员身份运行"
|
||||
|
||||
# 3. 服务会自动启动，开机自启动
|
||||
# 访问 http://localhost:5000
|
||||
|
||||
🛠️ 故障排除
|
||||
|
||||
┌──────────────────┬──────────────────────────────────────────┐
|
||||
│ 问题 │ 解决方案 │
|
||||
├──────────────────┼──────────────────────────────────────────┤
|
||||
│ 权限不足 │ 右键脚本 → "以管理员身份运行" │
|
||||
├──────────────────┼──────────────────────────────────────────┤
|
||||
│ 端口冲突 │ 修改 .env 中的 PORT 变量 │
|
||||
├──────────────────┼──────────────────────────────────────────┤
|
||||
│ pywin32 安装失败 │ 使用预编译版本：pip install pywin32==306 │
|
||||
├──────────────────┼──────────────────────────────────────────┤
|
||||
│ 虚拟环境激活失败 │ 确认 Python 路径正确：where python │
|
||||
├──────────────────┼──────────────────────────────────────────┤
|
||||
│ 服务启动失败 │ 查看日志：logs\service.log │
|
||||
└──────────────────┴──────────────────────────────────────────┘
|
||||
|
||||
🎯 推荐方案
|
||||
|
||||
个人使用/开发 → 使用 run_dev.py（简单快捷）
|
||||
|
||||
小型部署 → 使用 simple_windows_service.py + 开机启动
|
||||
|
||||
企业级部署 → 使用完整的 Windows 服务 (install_service.bat)
|
||||
|
||||
总结：aitsc 在 Windows 上的支持非常完善，既有简单的开发运行方式，也有专业的 Windows
|
||||
服务部署方案，完全可以满足从开发到生产的全链路需求。
|
||||
56
docs/Obsidian笔记体系/Projects/aitsc/wk4 aitsc 项目添加版本号 v1.0.0.md
Normal file
56
docs/Obsidian笔记体系/Projects/aitsc/wk4 aitsc 项目添加版本号 v1.0.0.md
Normal file
@@ -0,0 +1,56 @@
|
||||
● ✅ 已为 aitsc 项目添加版本号 v1.0.0
|
||||
|
||||
📋 版本配置详情
|
||||
|
||||
核心版本定义：
|
||||
- src/flask_prompt_master/__init__.py：添加 __version__ = '1.0.0' 和 __version_info__ = (1, 0, 0)
|
||||
- VERSION 文件：包含纯文本版本号 1.0.0
|
||||
|
||||
启动日志增强： 所有环境配置现在都会显示版本信息
|
||||
- config/development.py：开发环境启动时显示版本
|
||||
- config/production.py：生产环境启动时显示版本
|
||||
- config/testing.py：测试环境启动时显示版本
|
||||
- config/local.py：本地环境启动时显示版本
|
||||
- config/base.py：基础配置启动时显示版本
|
||||
|
||||
文档更新：
|
||||
- README.md：在标题下方添加版本信息 **版本**: v1.0.0
|
||||
|
||||
🔧 技术实现
|
||||
|
||||
1. 版本导入机制：通过 from src.flask_prompt_master import __version__ 安全导入版本信息
|
||||
2. 错误处理：导入失败时显示 "版本: 未知" 而不是崩溃
|
||||
3. 日志输出：在现有启动日志中追加版本信息，格式为 开发环境启动 - 版本: 1.0.0
|
||||
|
||||
🚀 验证结果
|
||||
|
||||
服务器重启后，启动日志已显示版本信息：
|
||||
[2026-04-02 17:51:04,431] INFO in development: <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> - <20>汾: 1.0.0
|
||||
2026-04-02 17:51:04,431 INFO: <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> - <20>汾: 1.0.0
|
||||
|
||||
📁 文件变更
|
||||
|
||||
aitsc/
|
||||
├── src/flask_prompt_master/__init__.py # 添加版本变量
|
||||
├── VERSION # 创建版本文件
|
||||
├── README.md # 更新文档
|
||||
├── config/
|
||||
│ ├── development.py # 开发环境版本日志
|
||||
│ ├── production.py # 生产环境版本日志
|
||||
│ ├── testing.py # 测试环境版本日志
|
||||
│ ├── local.py # 本地环境版本日志
|
||||
│ └── base.py # 基础配置版本日志
|
||||
|
||||
⚡ 使用说明
|
||||
|
||||
- 查看版本：服务器启动时自动在日志中显示
|
||||
- 代码引用：在代码中可通过 from src.flask_prompt_master import __version__ 获取
|
||||
- 文件查看：直接读取 VERSION 文件或查看 README.md
|
||||
|
||||
🔄 后续建议
|
||||
|
||||
1. 版本升级：修改 src/flask_prompt_master/__init__.py 和 VERSION 文件
|
||||
2. Git 标签：建议配合版本号创建 git tag：git tag -a v1.0.0 -m "Release v1.0.0"
|
||||
3. API 端点：如需通过 API 获取版本，可添加 /api/version 端点
|
||||
|
||||
版本号 v1.0.0 已成功集成到项目中，所有环境启动时都会明确显示当前版本。
|
||||
296
docs/Obsidian笔记体系/Projects/aitsc/wk5.md
Normal file
296
docs/Obsidian笔记体系/Projects/aitsc/wk5.md
Normal file
@@ -0,0 +1,296 @@
|
||||
Flask Prompt Master 项目重构方案
|
||||
|
||||
上下文和目标
|
||||
|
||||
项目概况：D:/aaa/aitsc 是一个 Flask 应用程序，提供多种 AI 驱动的功能（提示词模板、饭菜规划、旅行攻略、会议
|
||||
纪要、简历优化等）。项目采用蓝图架构，但随着功能增加出现了代码质量问题。
|
||||
|
||||
当前问题：
|
||||
1. 安全漏洞：多个路由文件中存在硬编码的 API 密钥和数据库密码
|
||||
2. 代码结构：routes.py 文件过大（1300+ 行），职责不单一
|
||||
3. API 设计不一致：多种响应格式和错误处理方式
|
||||
4. 认证系统碎片化：同时使用会话、令牌和微信认证
|
||||
5. 配置管理混乱：新旧配置系统并存
|
||||
6. 代码重复：相似功能间存在重复代码
|
||||
|
||||
重构目标：
|
||||
1. 消除安全漏洞，移除所有硬编码的敏感信息
|
||||
2. 提高代码可维护性，优化项目结构
|
||||
3. 标准化 API 设计和错误处理
|
||||
4. 集中化认证和授权系统
|
||||
5. 实现关注点分离（业务逻辑与表现层分离）
|
||||
|
||||
重构方案概述
|
||||
|
||||
目标架构
|
||||
|
||||
flask_prompt_master/
|
||||
├── app/ # 应用层（API/Web 路由）
|
||||
├── core/ # 核心业务逻辑（服务层）
|
||||
├── infrastructure/ # 基础设施（配置、数据库、外部服务）
|
||||
├── shared/ # 共享组件（工具类、数据模型、常量）
|
||||
├── tests/ # 测试套件
|
||||
└── docs/ # 文档
|
||||
|
||||
核心改进
|
||||
|
||||
6. 安全加固：环境变量管理，JWT 认证，安全头部
|
||||
7. API 标准化：统一响应格式，版本控制，OpenAPI 文档
|
||||
8. 代码重组：服务层提取，仓库模式，依赖注入
|
||||
9. 质量提升：测试覆盖率，CI/CD，代码质量工具
|
||||
|
||||
详细实施计划
|
||||
|
||||
阶段 1：安全加固与基础建设（第 1-2 周）
|
||||
|
||||
任务 1.1：消除硬编码敏感信息
|
||||
|
||||
- 优先级：高
|
||||
- 文件：
|
||||
- flask_prompt_master/routes.py:115 - 移除硬编码数据库密码
|
||||
- config.py - 移除已弃用的硬编码配置
|
||||
- 所有包含 sk-fdf7cc1c73504e628ec0119b7e11b8cc 的文件
|
||||
- 方法：
|
||||
a. 创建 .env.template 文件，列出所有需要的环境变量
|
||||
b. 更新配置系统，从环境变量读取所有敏感信息
|
||||
c. 添加配置验证，确保关键配置在启动时已设置
|
||||
|
||||
任务 1.2：实现统一认证中间件
|
||||
|
||||
- 优先级：高
|
||||
- 方法：
|
||||
a. 创建 auth/middleware.py 实现 JWT 认证中间件
|
||||
b. 统一所有 API 的认证方式，逐步替换现有的多种认证系统
|
||||
c. 添加角色和权限管理系统
|
||||
d. 实现刷新令牌机制
|
||||
|
||||
任务 1.3：添加安全头部和请求验证
|
||||
|
||||
- 优先级：中
|
||||
- 方法：
|
||||
a. 实现安全中间件，添加 CSP、HSTS、XSS 防护等头部
|
||||
b. 使用 Pydantic 创建请求数据验证模型
|
||||
c. 实现全局请求验证中间件
|
||||
|
||||
阶段 2：API 标准化与文档（第 3-4 周）
|
||||
|
||||
任务 2.1：创建标准 API 响应格式
|
||||
|
||||
- 优先级：高
|
||||
- 方法：
|
||||
a. 创建 shared/api/responses.py 定义标准响应类
|
||||
b. 实现成功响应：{success: true, data: {...}, meta: {...}}
|
||||
c. 实现错误响应：{success: false, error: {...}, error_code: string}
|
||||
d. 创建响应工具函数，统一所有路由的响应格式
|
||||
|
||||
任务 2.2：实现 API 版本控制
|
||||
|
||||
- 优先级：中
|
||||
- 方法：
|
||||
a. 创建 /api/v1/ 命名空间，所有新 API 使用此版本
|
||||
b. 保留现有 /api/ 路由作为 v0 版本，逐步迁移
|
||||
c. 实现版本路由中间件，支持通过 URL 或头部指定版本
|
||||
d. 添加 API 弃用警告机制
|
||||
|
||||
任务 2.3：添加 OpenAPI 文档
|
||||
|
||||
- 优先级：中
|
||||
- 方法：
|
||||
a. 使用 Flask-Swagger 或 FastAPI-style 注解
|
||||
b. 自动生成 API 文档，支持在线测试
|
||||
c. 添加 API 使用示例和错误代码说明
|
||||
|
||||
阶段 3：代码重组与服务层提取（第 5-6 周）
|
||||
|
||||
任务 3.1：分解大型路由文件
|
||||
|
||||
- 优先级：高
|
||||
- 文件：flask_prompt_master/routes.py（1300+ 行）
|
||||
- 方法：
|
||||
a. 按功能模块拆分：
|
||||
- routes/prompt_routes.py - 提示词相关路由
|
||||
- routes/auth_routes.py - 认证相关路由
|
||||
- routes/history_routes.py - 历史记录路由
|
||||
- routes/feature_routes.py - 各 AI 功能路由
|
||||
b. 每个文件不超过 300 行，保持单一职责
|
||||
c. 使用蓝图组织相关路由
|
||||
|
||||
任务 3.2：提取业务逻辑到服务层
|
||||
|
||||
- 优先级：高
|
||||
- 方法：
|
||||
a. 创建 services/ 目录，按领域划分服务类
|
||||
b. 将路由中的业务逻辑移动到对应服务类
|
||||
c. 服务类负责：业务规则验证、外部 API 调用、复杂数据处理
|
||||
d. 路由只负责：请求解析、响应格式化、错误处理
|
||||
|
||||
任务 3.3：实现仓库模式
|
||||
|
||||
- 优先级：中
|
||||
- 方法：
|
||||
a. 创建 repositories/ 目录，按实体划分仓库类
|
||||
b. 仓库类封装数据库操作，提供高层抽象接口
|
||||
c. 路由和服务通过仓库访问数据，不直接使用 SQLAlchemy
|
||||
d. 便于单元测试和数据库切换
|
||||
|
||||
阶段 4：测试与质量提升（第 7-8 周）
|
||||
|
||||
任务 4.1：提升测试覆盖率
|
||||
|
||||
- 优先级：中
|
||||
- 方法：
|
||||
a. 实现单元测试：服务层、仓库层、工具类
|
||||
b. 实现集成测试：API 端点测试
|
||||
c. 实现端到端测试：关键用户流程测试
|
||||
d. 目标：测试覆盖率从 ~40% 提升到 80%+
|
||||
|
||||
任务 4.2：实现 CI/CD 流水线
|
||||
|
||||
- 优先级：中
|
||||
- 方法：
|
||||
a. 设置 GitHub Actions 或 GitLab CI
|
||||
b. 自动化：代码检查、测试、构建、部署
|
||||
c. 添加质量门禁：测试覆盖率、代码复杂度、安全扫描
|
||||
|
||||
任务 4.3：代码质量工具集成
|
||||
|
||||
- 优先级：低
|
||||
- 方法：
|
||||
a. 集成 black、isort、flake8 代码格式化
|
||||
b. 添加 mypy 类型检查
|
||||
c. 集成 pre-commit hooks 自动执行代码检查
|
||||
|
||||
阶段 5：部署优化与文档（第 9-10 周）
|
||||
|
||||
任务 5.1：优化 Docker 部署
|
||||
|
||||
- 优先级：低
|
||||
- 方法：
|
||||
a. 优化 Dockerfile，减少镜像大小
|
||||
b. 实现多阶段构建
|
||||
c. 添加健康检查端点
|
||||
d. 优化生产环境配置
|
||||
|
||||
任务 5.2：实现监控和可观测性
|
||||
|
||||
- 优先级：中
|
||||
- 方法：
|
||||
a. 添加 Prometheus 指标收集
|
||||
b. 实现结构化日志记录
|
||||
c. 添加错误追踪和告警
|
||||
d. 实现性能监控
|
||||
|
||||
任务 5.3：完善文档
|
||||
|
||||
- 优先级：低
|
||||
- 方法：
|
||||
a. 架构设计文档
|
||||
b. API 使用文档
|
||||
c. 部署和维护指南
|
||||
d. 开发环境设置指南
|
||||
|
||||
风险缓解策略
|
||||
|
||||
技术风险
|
||||
|
||||
数据库迁移风险：
|
||||
- 使用 Alembic 生成迁移脚本
|
||||
- 在测试环境充分验证
|
||||
- 准备回滚方案
|
||||
API 兼容性风险：
|
||||
- 使用功能开关控制新功能
|
||||
- 保持向后兼容性至少一个版本周期
|
||||
- 提供详细的迁移指南
|
||||
性能回归风险：
|
||||
- 重构前后进行性能基准测试
|
||||
- 实施监控和告警
|
||||
- 准备快速回滚机制
|
||||
|
||||
实施风险
|
||||
|
||||
团队知识差距：
|
||||
- 结对编程和代码审查
|
||||
- 详细的架构文档
|
||||
- 定期知识分享会议
|
||||
时间安排风险：
|
||||
- 采用敏捷方法，每两周评估进度
|
||||
- 优先处理高价值任务
|
||||
- 保持灵活性，根据进展调整计划
|
||||
|
||||
关键文件路径
|
||||
|
||||
需要立即处理的安全问题
|
||||
|
||||
1. D:/aaa/aitsc/src/flask_prompt_master/routes/routes.py:115 - 硬编码数据库密码
|
||||
2. D:/aaa/aitsc/config.py - 已弃用的硬编码配置
|
||||
3. 所有包含硬编码 API 密钥的文件（搜索 sk-fdf7cc1c73504e628ec0119b7e11b8cc）
|
||||
|
||||
大型文件需要拆分
|
||||
|
||||
4. D:/aaa/aitsc/src/flask_prompt_master/routes/routes.py（1300+ 行）
|
||||
5. D:/aaa/aitsc/src/flask_prompt_master/models/models.py（500+ 行）
|
||||
|
||||
新目录结构
|
||||
|
||||
6. src/flask_prompt_master/services/ - 服务层
|
||||
7. src/flask_prompt_master/repositories/ - 仓库层
|
||||
8. src/flask_prompt_master/shared/ - 共享组件
|
||||
9. src/flask_prompt_master/api/ - API 相关组件
|
||||
|
||||
验证和测试策略
|
||||
|
||||
验证步骤
|
||||
|
||||
10. 安全验证：确保无硬编码敏感信息，所有配置通过环境变量管理
|
||||
11. 功能验证：所有现有功能测试通过，API 响应格式一致
|
||||
12. 性能验证：关键 API 端点响应时间无显著下降
|
||||
13. 部署验证：生产环境部署成功，监控系统正常运行
|
||||
|
||||
测试计划
|
||||
|
||||
14. 单元测试：服务层、仓库层、工具类
|
||||
15. 集成测试：API 端点、数据库操作
|
||||
16. 端到端测试：关键用户流程（注册、登录、使用功能）
|
||||
17. 性能测试：负载测试、压力测试
|
||||
|
||||
成功指标
|
||||
|
||||
量化指标
|
||||
|
||||
18. 零硬编码敏感信息
|
||||
19. 测试覆盖率 80%+
|
||||
20. 代码复杂度降低 30%
|
||||
21. API 平均响应时间改善 20%
|
||||
22. 缺陷修复时间减少 50%
|
||||
|
||||
质化指标
|
||||
|
||||
23. 新开发者上手时间减少 50%
|
||||
24. 完整的架构和 API 文档
|
||||
25. 开发者满意度提升
|
||||
26. 部署信心增强
|
||||
|
||||
资源需求
|
||||
|
||||
团队配置
|
||||
|
||||
- 2-3 名高级开发工程师
|
||||
- 兼职 QA 工程师
|
||||
- 技术负责人（架构决策和代码审查）
|
||||
|
||||
时间安排
|
||||
|
||||
- 总时长：10 周（2.5 个月）
|
||||
- 开发工作量：约 400-500 人时
|
||||
- 每周进度评审和调整
|
||||
|
||||
工具和环境
|
||||
|
||||
- CI/CD 流水线
|
||||
- 测试环境（开发、测试、预生产）
|
||||
- 监控和告警系统
|
||||
- 文档管理系统
|
||||
|
||||
---
|
||||
注意：本重构计划采用渐进式方法，每个阶段都有明确的可交付成果和验证标准。建议从阶段 1
|
||||
开始，确保安全基础稳固后再进行架构优化。
|
||||
134
docs/Obsidian笔记体系/Projects/aitsc/wk6.md
Normal file
134
docs/Obsidian笔记体系/Projects/aitsc/wk6.md
Normal file
@@ -0,0 +1,134 @@
|
||||
● 基于对 http://127.0.0.1:5002/ 页面的分析，这是一个设计良好的AI提示词模板应用，采用深蓝色科技感主题，具备现
|
||||
代化UI和响应式设计。从用户体验角度，以下是可以改进的地方：
|
||||
|
||||
当前优点
|
||||
|
||||
1. 视觉设计优秀：深蓝色科技主题、CSS变量、渐变效果、阴影层次
|
||||
2. 响应式完善：移动端适配良好，侧边栏在小屏幕下可切换
|
||||
3. 功能丰富：筛选、收藏、复制、删除、使用统计一应俱全
|
||||
4. 交互细节：悬停效果、平滑滚动、键盘导航支持
|
||||
5. 性能考虑：图片懒加载、防抖搜索
|
||||
|
||||
用户体验改进建议
|
||||
|
||||
6. 首屏信息密度与引导
|
||||
|
||||
- 问题：页面加载后，用户不清楚主要操作是什么
|
||||
- 改进：
|
||||
- 在模板网格上方添加简短引导语："选择模板开始生成专业提示词"
|
||||
- 为首次访问用户添加引导遮罩或提示泡泡
|
||||
- 在空白筛选区域增加"试试选择行业和职业来筛选模板"
|
||||
|
||||
2. 筛选系统优化
|
||||
|
||||
- 当前问题：
|
||||
- 三个下拉筛选器（行业、职业、领域）选项过多（每个50+选项）
|
||||
- 没有搜索筛选器功能
|
||||
- 筛选状态不直观
|
||||
- 改进：
|
||||
- 为下拉筛选添加搜索框，支持输入筛选
|
||||
- 显示当前应用的筛选条件（如："行业: 互联网 | 职业: 开发工程师"）
|
||||
- 添加"清除所有筛选"按钮
|
||||
- 考虑将部分筛选改为标签式选择（热门行业/职业）
|
||||
|
||||
3. 模板卡片信息展示
|
||||
|
||||
- 当前问题：
|
||||
- 部分模板卡片行业/职业/领域信息为空
|
||||
- 使用统计（0次使用）对用户决策价值有限
|
||||
- 模板难度级别（初级）缺乏解释
|
||||
- 改进：
|
||||
- 隐藏空的信息字段
|
||||
- 将"使用次数"改为"热度"或添加"推荐"标签
|
||||
- 为难度级别添加工具提示："初级：适合初学者"
|
||||
- 增加模板预览功能（鼠标悬停显示摘要）
|
||||
|
||||
4. 操作流程优化
|
||||
|
||||
- 当前问题：
|
||||
- 需要先选择模板，然后输入文本，再生成提示词
|
||||
- 操作路径不够直观
|
||||
- 改进：
|
||||
- 将输入区域放在更显眼位置（模板网格上方或左侧）
|
||||
- 实现"选择即生成"模式：选择模板后自动生成示例提示词
|
||||
- 添加"快速开始"区域，推荐3-5个最常用模板
|
||||
|
||||
5. 移动端体验提升
|
||||
|
||||
- 当前问题：
|
||||
- 侧边栏筛选在小屏幕上操作不便
|
||||
- 模板卡片在手机上信息显示拥挤
|
||||
- 改进：
|
||||
- 将筛选改为底部抽屉式，更方便单手操作
|
||||
- 简化移动端模板卡片，隐藏次要信息
|
||||
- 优化触控目标大小（按钮至少44×44px）
|
||||
|
||||
6. 搜索与发现
|
||||
|
||||
- 当前问题：页面似乎缺少全局搜索功能
|
||||
- 改进：
|
||||
- 在导航栏添加搜索框，支持模板名称和内容搜索
|
||||
- 添加"最近使用"、"热门模板"、"新添加"等分类
|
||||
- 实现搜索建议和自动完成
|
||||
|
||||
7. 反馈与确认
|
||||
|
||||
- 当前问题：
|
||||
- 删除操作直接执行，没有确认对话框
|
||||
- 操作成功/失败反馈依赖alert()
|
||||
- 改进：
|
||||
- 重要操作（删除、清空）添加确认对话框
|
||||
- 用非模态提示（toast）替代alert()，减少干扰
|
||||
- 添加操作撤销功能（如误删除后5秒内可撤销）
|
||||
|
||||
8. 性能与加载体验
|
||||
|
||||
- 当前问题：
|
||||
- 页面6178行，CSS和JS都在一个文件中
|
||||
- 初始加载可能较慢
|
||||
- 改进：
|
||||
- 分离CSS和JS到外部文件，利用浏览器缓存
|
||||
- 实现骨架屏加载效果
|
||||
- 优先加载首屏内容，延迟加载非关键资源
|
||||
|
||||
9. 可访问性增强
|
||||
|
||||
- 当前问题：
|
||||
- 虽然支持键盘导航，但ARIA属性不完整
|
||||
- 颜色对比度可以进一步优化
|
||||
- 改进：
|
||||
- 为所有交互元素添加完整的ARIA标签
|
||||
- 确保颜色对比度满足WCAG AA标准
|
||||
- 添加跳过导航链接，方便屏幕阅读器用户
|
||||
|
||||
10. 新手引导与帮助
|
||||
|
||||
- 当前问题：缺乏使用指导和帮助文档
|
||||
- 改进：
|
||||
- 添加"如何使用"页面或引导教程
|
||||
- 在复杂功能旁添加问号图标，点击显示简短说明
|
||||
- 创建视频教程或图文指南
|
||||
|
||||
具体实施优先级
|
||||
|
||||
高优先级（立即改进）：
|
||||
1. 添加筛选状态显示和清除按钮
|
||||
2. 为删除操作添加确认对话框
|
||||
3. 优化移动端筛选交互
|
||||
|
||||
中优先级（短期改进）：
|
||||
4. 增加全局搜索功能
|
||||
5. 优化模板卡片信息展示
|
||||
6. 添加新手引导
|
||||
|
||||
低优先级（长期优化）：
|
||||
7. 分离资源文件，优化加载性能
|
||||
8. 增强可访问性支持
|
||||
9. 创建完整的帮助系统
|
||||
|
||||
总结
|
||||
|
||||
这个应用已经有了很好的基础，主要需要优化的是用户引导、操作效率和移动端体验。最关键的改进点是让用户更快理解
|
||||
如何使用，并减少操作步骤的认知负担。
|
||||
|
||||
建议先从添加筛选状态显示和优化移动端交互开始，这两项改进成本低但用户体验提升明显。
|
||||
145
docs/Obsidian笔记体系/Projects/aitsc/wk7.md
Normal file
145
docs/Obsidian笔记体系/Projects/aitsc/wk7.md
Normal file
@@ -0,0 +1,145 @@
|
||||
当前设计的优点
|
||||
|
||||
- 现代科技感设计：深蓝色主题、渐变效果、卡片布局
|
||||
- 响应式布局：适配桌面、平板、手机
|
||||
- 功能完整：侧边栏筛选、模板卡片、搜索、用户系统
|
||||
- 交互反馈：悬停效果、过渡动画
|
||||
- 技术先进：CSS变量、Bootstrap 5、Font Awesome
|
||||
|
||||
美观方面可改进的地方
|
||||
|
||||
1. 颜色对比度与可访问性
|
||||
|
||||
- 检查文字颜色（特别是 --text-light: #64748B）在浅色背景上的对比度，确保符合WCAG 2.1 AA标准
|
||||
- 焦点状态颜色需要更明显（当前 box-shadow: 0 0 0 2px rgba(33, 150, 243, 0.2) 对比度不足）
|
||||
- 为色盲用户考虑，重要的状态指示（如成功/错误）应同时使用颜色和图标
|
||||
|
||||
2. 视觉层次与间距
|
||||
|
||||
- 虽然定义了间距变量（--spacing-unit: 0.25rem），但实际使用中不够一致
|
||||
- 标题层级可以更清晰：主标题 h1 使用频率不足
|
||||
- 卡片内边距可以优化，避免内容过于拥挤
|
||||
|
||||
3. 卡片设计优化
|
||||
|
||||
/* 建议改进 */
|
||||
.template-card {
|
||||
border-radius: var(--border-radius-lg); /* 当前 12px，可统一为 16px */
|
||||
box-shadow: var(--shadow-md); /* 当前阴影较弱 */
|
||||
transition: transform 0.2s ease, box-shadow 0.2s ease;
|
||||
}
|
||||
.template-card:hover {
|
||||
transform: translateY(-4px); /* 当前 -1px，效果不明显 */
|
||||
box-shadow: var(--shadow-lg);
|
||||
}
|
||||
|
||||
4. 图标一致性
|
||||
|
||||
- 确保所有图标大小统一（当前导航图标 1rem，用户菜单图标 1.5rem）
|
||||
- 考虑使用更一致的图标集（如全部使用 fas 或 far）
|
||||
|
||||
5. 加载与空状态
|
||||
|
||||
- 添加骨架屏加载动画
|
||||
- 设计友好的空状态界面（无搜索结果、无收藏等）
|
||||
|
||||
用户体验方面可改进的地方
|
||||
|
||||
1. 筛选器体验
|
||||
|
||||
- 问题：领域下拉菜单有101个选项，难以查找
|
||||
- 改进：添加搜索框或分组显示，或改为标签云式多选
|
||||
|
||||
2. 搜索功能
|
||||
|
||||
- 添加实时搜索反馈（显示匹配数量）
|
||||
- 搜索历史记录/热门搜索建议
|
||||
- 搜索框添加清除按钮
|
||||
|
||||
3. 键盘导航与可访问性
|
||||
|
||||
<!-- 添加ARIA属性 -->
|
||||
<div class="template-card" role="option" aria-selected="false" tabindex="0">
|
||||
- 确保所有交互元素都有清晰的焦点样式
|
||||
- 支持ESC键关闭侧边栏和模态框
|
||||
|
||||
4. 移动端优化
|
||||
|
||||
- 侧边栏抽屉可以添加手势支持（右滑关闭）
|
||||
- 底部操作栏在移动端可固定定位
|
||||
- 触摸目标大小至少44×44px（当前部分按钮较小）
|
||||
|
||||
5. 表单与交互反馈
|
||||
|
||||
- 实时验证文本区域输入（字数统计、内容质量提示）
|
||||
- 操作成功/失败 Toast 通知（替代当前 alert()）
|
||||
- 防止重复提交（提交按钮禁用状态）
|
||||
|
||||
6. 性能优化
|
||||
|
||||
- 大量模板卡片（未来可能增加）考虑虚拟滚动
|
||||
- 图片/图标懒加载
|
||||
- 减少首屏CSS（将非关键CSS异步加载）
|
||||
|
||||
7. 引导与帮助
|
||||
|
||||
- 首次使用引导（高亮核心功能）
|
||||
- 模板说明可以添加"了解更多"展开项
|
||||
- 帮助按钮或文档链接
|
||||
|
||||
8. 错误处理
|
||||
|
||||
- 网络错误时提供重试按钮
|
||||
- 表单提交失败保留用户输入
|
||||
- 友好的404/500错误页面
|
||||
|
||||
具体技术建议
|
||||
|
||||
1. CSS优化
|
||||
|
||||
/* 添加 prefers-reduced-motion 支持 */
|
||||
@media (prefers-reduced-motion: reduce) {
|
||||
* {
|
||||
animation-duration: 0.01ms !important;
|
||||
transition-duration: 0.01ms !important;
|
||||
}
|
||||
}
|
||||
|
||||
/* 暗色模式支持 */
|
||||
@media (prefers-color-scheme: dark) {
|
||||
:root {
|
||||
--background-color: #0f172a;
|
||||
--text-color: #f8fafc;
|
||||
}
|
||||
}
|
||||
|
||||
2. JavaScript增强
|
||||
|
||||
- 添加离线检测和提示
|
||||
- 使用本地存储保存用户偏好（侧边栏状态、筛选条件）
|
||||
- 实现撤销/重做操作（特别是模板选择）
|
||||
|
||||
3. SEO与分享优化
|
||||
|
||||
- 添加Open Graph meta标签
|
||||
- 结构化数据标记（JSON-LD）
|
||||
- 页面标题动态更新（当前固定为"提示词大师 - AI应用"）
|
||||
|
||||
优先级建议
|
||||
|
||||
高优先级：
|
||||
1. 键盘导航与可访问性修复
|
||||
2. 移动端触摸目标大小调整
|
||||
3. 筛选器搜索功能添加
|
||||
|
||||
中优先级：
|
||||
4. 加载状态与错误处理
|
||||
5. 颜色对比度检查
|
||||
6. 性能优化（虚拟滚动）
|
||||
|
||||
低优先级：
|
||||
7. 暗色模式
|
||||
8. 动画微调
|
||||
9. SEO优化
|
||||
|
||||
这些改进将显著提升用户满意度、可访问性和整体专业感。需要进一步检查具体实现代码，我可以帮助实现其中任何一项改进。
|
||||
217
docs/Obsidian笔记体系/Projects/aitsc/wk8.md
Normal file
217
docs/Obsidian笔记体系/Projects/aitsc/wk8.md
Normal file
@@ -0,0 +1,217 @@
|
||||
1. 项目现状评估
|
||||
|
||||
1.1 核心功能模块清单
|
||||
|
||||
项目是一个多功能AI提示词生成与管理平台，采用Flask + 服务器端渲染架构，包含以下15个核心模块：
|
||||
|
||||
┌──────────┬──────────────────────────────────────────────────────────────┬──────────────────────────┐
|
||||
│ 模块类别 │ 功能描述 │ 技术实现 │
|
||||
├──────────┼──────────────────────────────────────────────────────────────┼──────────────────────────┤
|
||||
│ 核心生成 │ 主提示词生成（默认模板） │ Flask路由 + OpenAI API │
|
||||
├──────────┼──────────────────────────────────────────────────────────────┼──────────────────────────┤
|
||||
│ 用户体系 │ 用户认证、微信小程序集成 │ Flask-Login + WxUser模型 │
|
||||
├──────────┼──────────────────────────────────────────────────────────────┼──────────────────────────┤
|
||||
│ 数据管理 │ 收藏管理、历史记录 │ SQLAlchemy + 关系模型 │
|
||||
├──────────┼──────────────────────────────────────────────────────────────┼──────────────────────────┤
|
||||
│ 垂直场景 │ 饭菜规划、古诗词解析、周报生成、旅行规划、会议纪要、简历优化 │ 专用蓝图 + 模板 │
|
||||
├──────────┼──────────────────────────────────────────────────────────────┼──────────────────────────┤
|
||||
│ 专家模式 │ 智能提示词优化（3个独立实现） │ 多版本对比优化 │
|
||||
├──────────┼──────────────────────────────────────────────────────────────┼──────────────────────────┤
|
||||
│ 开发工具 │ Android工程师专区（Crash解读、依赖冲突分析） │ 专业场景模板 │
|
||||
├──────────┼──────────────────────────────────────────────────────────────┼──────────────────────────┤
|
||||
│ 管理后台 │ 数据分析、监控、批量操作 │ Flask-Admin扩展 │
|
||||
├──────────┼──────────────────────────────────────────────────────────────┼──────────────────────────┤
|
||||
│ 扩展预留 │ 占位应用（预留扩展位） │ 模块化设计 │
|
||||
└──────────┴──────────────────────────────────────────────────────────────┴──────────────────────────┘
|
||||
|
||||
1.2 技术栈组成与版本
|
||||
|
||||
┌──────────┬─────────────────────────────────────────────┬──────────────────────────────────┐
|
||||
│ 层级 │ 技术栈 │ 版本/备注 │
|
||||
├──────────┼─────────────────────────────────────────────┼──────────────────────────────────┤
|
||||
│ 后端框架 │ Python Flask │ ≥2.2.0 │
|
||||
├──────────┼─────────────────────────────────────────────┼──────────────────────────────────┤
|
||||
│ ORM │ Flask-SQLAlchemy │ ≥3.0.2 │
|
||||
├──────────┼─────────────────────────────────────────────┼──────────────────────────────────┤
|
||||
│ 数据库 │ MySQL 8.0 + Redis 7 │ 容器化部署 │
|
||||
├──────────┼─────────────────────────────────────────────┼──────────────────────────────────┤
|
||||
│ AI集成 │ OpenAI兼容API (DeepSeek) │ 硬编码API密钥（安全风险） │
|
||||
├──────────┼─────────────────────────────────────────────┼──────────────────────────────────┤
|
||||
│ 前端UI │ Bootstrap 5.1 + jQuery 3.6 │ CDN加载 │
|
||||
├──────────┼─────────────────────────────────────────────┼──────────────────────────────────┤
|
||||
│ 前端交互 │ 原生JavaScript + 自定义CSS │ 未使用构建工具 │
|
||||
├──────────┼─────────────────────────────────────────────┼──────────────────────────────────┤
|
||||
│ 部署架构 │ Docker Compose 3.8 + Nginx │ 四服务编排（App/DB/Redis/Nginx） │
|
||||
├──────────┼─────────────────────────────────────────────┼──────────────────────────────────┤
|
||||
│ 辅助工具 │ Flask-Migrate、Flask-CORS、bcrypt、waitress │ 完整生产配置 │
|
||||
└──────────┴─────────────────────────────────────────────┴──────────────────────────────────┘
|
||||
|
||||
1.3 系统部署架构图
|
||||
|
||||
[用户请求]
|
||||
↓
|
||||
[Nginx:80/443]
|
||||
↓
|
||||
┌──────────────┼──────────────┐
|
||||
↓ ↓ ↓
|
||||
[Flask App] [MySQL 8.0] [Redis 7]
|
||||
(端口:5000) (端口:3306) (端口:6379)
|
||||
│ │ │
|
||||
└──────────────┼──────────────┘
|
||||
↓
|
||||
[静态文件/模板渲染]
|
||||
|
||||
---
|
||||
2. 优势与痛点诊断
|
||||
|
||||
2.1 技术优势（≥3项）
|
||||
|
||||
1. 模块化架构清晰：采用Flask蓝图设计，功能解耦良好，新增模块只需注册新蓝图
|
||||
2. 生产就绪的部署方案：完整Docker Compose配置，包含Nginx反向代理、数据库持久化、日志轮转
|
||||
3. 错误处理机制完善：全局500错误处理、API调用重试机制、结构化日志记录
|
||||
4. 多环境配置支持：基于config/目录的配置系统，支持development/testing/production环境
|
||||
5. 数据库迁移管理：使用Flask-Migrate，支持平滑升级和数据迁移
|
||||
|
||||
2.2 性能指标（基于代码分析）
|
||||
|
||||
- API响应时间：LLM调用设置60秒超时，含3次重试机制
|
||||
- 数据库连接池：SQLAlchemy配置连接池（pool_size=20, max_overflow=30）
|
||||
- 缓存策略：Redis缓存支持，默认超时1小时
|
||||
- 前端资源体积：CSS 1.1KB + JS 1.2KB（未压缩），Bootstrap/jQuery使用CDN
|
||||
|
||||
2.3 痛点与技术债务
|
||||
|
||||
┌──────────┬──────────────────────────────────────────────────┬─────────────────────────────────┐
|
||||
│ 风险等级 │ 问题描述 │ 影响范围 │
|
||||
├──────────┼──────────────────────────────────────────────────┼─────────────────────────────────┤
|
||||
│ 高危 │ API密钥硬编码于routes/routes.py:21 │ 安全漏洞，密钥泄露风险 │
|
||||
├──────────┼──────────────────────────────────────────────────┼─────────────────────────────────┤
|
||||
│ 高危 │ 用户密码使用自定义哈希（login_pwd + login_salt） │ 密码安全强度不足 │
|
||||
├──────────┼──────────────────────────────────────────────────┼─────────────────────────────────┤
|
||||
│ 中危 │ CORS配置过于宽松（默认['*']） │ 生产环境跨域安全风险 │
|
||||
├──────────┼──────────────────────────────────────────────────┼─────────────────────────────────┤
|
||||
│ 中危 │ 前端资源未压缩（无构建流程） │ 页面加载性能损失约30% │
|
||||
├──────────┼──────────────────────────────────────────────────┼─────────────────────────────────┤
|
||||
│ 中危 │ 代码重复（expert_generate多个版本） │ 维护成本增加，bug修复需多处修改 │
|
||||
├──────────┼──────────────────────────────────────────────────┼─────────────────────────────────┤
|
||||
│ 低危 │ 缺乏自动化测试覆盖 │ 回归测试依赖手动验证 │
|
||||
└──────────┴──────────────────────────────────────────────────┴─────────────────────────────────┘
|
||||
|
||||
---
|
||||
3. 用户体验专项审计
|
||||
|
||||
3.1 技术指标检测（基于运行中服务 http://127.0.0.1:5002/）
|
||||
|
||||
┌────────────────┬──────────────────────────────────────┬───────────────────────────────┐
|
||||
│ 指标 │ 现状评估 │ 建议 │
|
||||
├────────────────┼──────────────────────────────────────┼───────────────────────────────┤
|
||||
│ Lighthouse性能 │ 预估得分：65-75/100 │ 资源未压缩、无懒加载 │
|
||||
├────────────────┼──────────────────────────────────────┼───────────────────────────────┤
|
||||
│ 可访问性 │ 基础合规（Bootstrap提供基础支持） │ 缺少ARIA标签、键盘导航支持 │
|
||||
├────────────────┼──────────────────────────────────────┼───────────────────────────────┤
|
||||
│ SEO优化 │ 基础达标（meta描述、og标签齐全） │ 可添加结构化数据、sitemap │
|
||||
├────────────────┼──────────────────────────────────────┼───────────────────────────────┤
|
||||
│ 首屏加载 │ 1.5-2.5秒（依赖CDN网络状况） │ 内联关键CSS、异步加载非关键JS │
|
||||
├────────────────┼──────────────────────────────────────┼───────────────────────────────┤
|
||||
│ 资源压缩 │ 未压缩（CSS 1.1KB, JS 1.2KB） │ 引入构建流程（Vite/webpack） │
|
||||
├────────────────┼──────────────────────────────────────┼───────────────────────────────┤
|
||||
│ 移动端适配 │ 响应式设计（Bootstrap 5 + viewport） │ 通过测试 │
|
||||
├────────────────┼──────────────────────────────────────┼───────────────────────────────┤
|
||||
│ 浏览器兼容 │ 现代浏览器支持良好 │ IE11及以下不兼容（符合预期） │
|
||||
└────────────────┴──────────────────────────────────────┴───────────────────────────────┘
|
||||
|
||||
3.2 交互体验评估
|
||||
|
||||
- 核心操作路径：表单提交→加载状态→结果显示，流程完整但缺乏进度反馈
|
||||
- 错误处理机制：前端有基础验证，后端返回JSON错误格式，但错误提示不友好
|
||||
- 无障碍设计：仅基础HTML语义化，缺少屏幕阅读器优化、焦点管理
|
||||
- 动画与反馈：使用CSS过渡效果，但加载状态依赖按钮文字变更
|
||||
|
||||
---
|
||||
4. Vue.js重构可行性研究
|
||||
|
||||
4.1 技术对比矩阵（评分1-10分）
|
||||
|
||||
┌──────────────┬────────────────────────────┬─────────────────────────────────┬──────┬──────────┬─────────┐
|
||||
│ 维度 │ 当前方案（jQuery+SSR） │ Vue 3方案（SPA+组件化） │ 权重 │ 当前得分 │ Vue得分 │
|
||||
├──────────────┼────────────────────────────┼─────────────────────────────────┼──────┼──────────┼─────────┤
|
||||
│ 开发效率 │ 前后端耦合，调试需重启服务 │ 组件化开发、热重载、DevTools │ 30% │ 6.0 │ 8.5 │
|
||||
├──────────────┼────────────────────────────┼─────────────────────────────────┼──────┼──────────┼─────────┤
|
||||
│ 维护成本 │ 全局状态管理困难，代码重复 │ 组件复用率高，状态集中管理 │ 25% │ 5.0 │ 8.0 │
|
||||
├──────────────┼────────────────────────────┼─────────────────────────────────┼──────┼──────────┼─────────┤
|
||||
│ 性能表现 │ 首屏快但页面跳转需重载 │ SPA切换快，首屏需加载bundle │ 20% │ 7.0 │ 8.0 │
|
||||
├──────────────┼────────────────────────────┼─────────────────────────────────┼──────┼──────────┼─────────┤
|
||||
│ 生态支持 │ jQuery插件丰富但陈旧 │ Vue Router、Pinia、Vite生态完善 │ 15% │ 7.0 │ 9.0 │
|
||||
├──────────────┼────────────────────────────┼─────────────────────────────────┼──────┼──────────┼─────────┤
|
||||
│ 团队适配 │ 熟悉jQuery，学习曲线平缓 │ 需学习Vue 3组合式API │ 10% │ 8.0 │ 6.0 │
|
||||
├──────────────┼────────────────────────────┼─────────────────────────────────┼──────┼──────────┼─────────┤
|
||||
│ 综合加权得分 │ 6.35 │ 8.08 │ 100% │ │ │
|
||||
└──────────────┴────────────────────────────┴─────────────────────────────────┴──────┴──────────┴─────────┘
|
||||
|
||||
结论：Vue 3方案综合得分提升27.2%，主要在开发效率、维护成本、生态支持方面优势明显。
|
||||
|
||||
4.2 迁移风险评估
|
||||
|
||||
┌────────────────┬────────────────────────────────┬─────────────────────────────────────────┐
|
||||
│ 风险类型 │ 风险描述 │ 缓解措施 │
|
||||
├────────────────┼────────────────────────────────┼─────────────────────────────────────────┤
|
||||
│ 增量迁移复杂性 │ 如何逐步替换现有jQuery代码 │ 采用微前端架构，新旧系统并行运行 │
|
||||
├────────────────┼────────────────────────────────┼─────────────────────────────────────────┤
|
||||
│ 数据层兼容性 │ 现有API需要适配Vue前端调用模式 │ 保持RESTful API不变，仅前端消费方式变化 │
|
||||
├────────────────┼────────────────────────────────┼─────────────────────────────────────────┤
|
||||
│ 第三方依赖适配 │ jQuery插件需替换为Vue组件 │ 评估替代方案（如Bootstrap Vue） │
|
||||
├────────────────┼────────────────────────────────┼─────────────────────────────────────────┤
|
||||
│ 团队技能缺口 │ 需培训Vue 3开发技能 │ 分阶段培训 + 引入外部专家支持 │
|
||||
├────────────────┼────────────────────────────────┼─────────────────────────────────────────┤
|
||||
│ ROI分析 │ 迁移成本 vs 长期收益 │ 预计6-9个月收回投资（基于维护成本降低） │
|
||||
└────────────────┴────────────────────────────────┴─────────────────────────────────────────┘
|
||||
|
||||
4.3 实施路线图建议
|
||||
|
||||
阶段一：搭建Vue 3微前端试验田（1-2个月）
|
||||
|
||||
- 技术选型：Vue 3 + Vite + Pinia + Vue Router
|
||||
- 基础设施：独立/vue-app目录，与现有Flask静态资源并行
|
||||
- 试点模块：选择收藏管理模块进行重构
|
||||
- 集成方案：使用<micro-frontend>容器渐进式加载Vue组件
|
||||
|
||||
阶段二：核心模块渐进式重构（3-4个月）
|
||||
|
||||
- 优先级：用户中心 → 历史记录 → 提示词生成
|
||||
- 数据层：封装现有API为TypeScript接口
|
||||
- 状态管理：统一使用Pinia，与现有session并行
|
||||
- 组件库：基于Bootstrap Vue建立企业级组件库
|
||||
|
||||
阶段三：新旧架构并行运行验证（1-2个月）
|
||||
|
||||
- A/B测试：50%流量导向Vue新架构
|
||||
- 性能监控：对比关键指标（首屏加载、交互响应时间）
|
||||
- 用户反馈：收集UX改进建议
|
||||
- 问题修复：针对并行运行暴露的问题进行修复
|
||||
|
||||
阶段四：完整迁移与性能调优（2-3个月）
|
||||
|
||||
- 全面切换：100%流量切至Vue架构
|
||||
- 代码清理：移除遗留jQuery代码
|
||||
- 性能优化：代码分割、懒加载、CDN部署
|
||||
- 文档完善：更新开发文档、部署指南
|
||||
|
||||
---
|
||||
5. 紧急行动建议（立即执行）
|
||||
|
||||
安全修复（24小时内）：
|
||||
- 移除routes/routes.py:21硬编码的API密钥，改用环境变量
|
||||
- 收紧生产环境CORS配置，指定允许的域名列表
|
||||
性能优化（1周内）：
|
||||
- 配置Nginx启用gzip压缩静态资源
|
||||
- 添加Cache-Control头部优化缓存策略
|
||||
代码质量（2周内）：
|
||||
- 合并expert_generate重复代码，提取公共组件
|
||||
- 引入基础单元测试，覆盖核心API路由
|
||||
重构准备（1个月内）：
|
||||
- 评估团队Vue技能现状，制定培训计划
|
||||
- 搭建Vue 3试验环境，验证技术选型可行性
|
||||
|
||||
---
|
||||
报告说明：本评估基于静态代码分析和运行中服务测试，实际性能指标可能因部署环境而异。Vue重构建议需要根据团队实际情况调整
|
||||
实施节奏。
|
||||
9
docs/Obsidian笔记体系/Projects/aitsc/下任务.md
Normal file
9
docs/Obsidian笔记体系/Projects/aitsc/下任务.md
Normal file
@@ -0,0 +1,9 @@
|
||||
|
||||
|
||||
|
||||
D:\aaa\aitsc\上传git仓.md
|
||||
将修改上传到git仓rjb_win_dev分支
|
||||
http://101.43.95.130:3001/admin/aitsc.git
|
||||
|
||||
|
||||
D:\aaa\aitsc\改进计划.md
|
||||
@@ -1,4 +1,46 @@
|
||||
cd D:\cd\claude-code
|
||||
bun install
|
||||
bun run build
|
||||
bun run dev
|
||||
bun run dev
|
||||
|
||||
|
||||
cd D:\cd\claude-code
|
||||
bun run dev
|
||||
|
||||
cd D:\cd\claude-code
|
||||
$env:ANTHROPIC_API_KEY="sk-fdf7cc1c73504e628ec0119b7e11b8cc"
|
||||
$env:ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic"
|
||||
bun run dev
|
||||
|
||||
|
||||
|
||||
ali模型
|
||||
cd D:\cd\claude-code
|
||||
$env:ANTHROPIC_API_KEY="sk-67c44b5e3faf4b9a9e6099ed2d89f1f9"
|
||||
$env:ANTHROPIC_BASE_URL="https://dashscope.aliyuncs.com/compatible-mode/v1"
|
||||
$env:MODEL_NAME="qwen-max"
|
||||
bun run dev
|
||||
|
||||
|
||||
|
||||
|
||||
$env:HTTP_PROXY="http://127.0.0.1:你的代理端口"
|
||||
$env:HTTPS_PROXY="http://127.0.0.1:你的代理端口"
|
||||
$env:ANTHROPIC_API_KEY="sk-fdf7cc1c73504e628ec0119b7e11b8cc"
|
||||
bun run dev
|
||||
|
||||
|
||||
cd D:\cd\claude-code
|
||||
$env:ANTHROPIC_API_KEY="sk-fdf7cc1c73504e628ec0119b7e11b8cc"
|
||||
$env:ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic"
|
||||
bun run dev
|
||||
|
||||
|
||||
|
||||
启动claude
|
||||
cd D:\cd\claude-code
|
||||
$env:ANTHROPIC_API_KEY="sk-fdf7cc1c73504e628ec0119b7e11b8cc"
|
||||
$env:ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic"
|
||||
$env:ANTHROPIC_MODEL="deepseek-v4-pro"
|
||||
bun run dev
|
||||
|
||||
|
||||
64
docs/Obsidian笔记体系/Projects/claude code/temp.md
Normal file
64
docs/Obsidian笔记体系/Projects/claude code/temp.md
Normal file
@@ -0,0 +1,64 @@
|
||||
按计划D:\aaa\aiagent\AI agent改造计划.md
|
||||
接下来该做什么？
|
||||
|
||||
|
||||
更新D:\aaa\aiagent\自主AI Agent改造完成情况.md
|
||||
|
||||
更新D:\aaa\aiagent\(红头)项目核心文档汇总.md
|
||||
D:\aaa\aiagent\(红头)Windows服务器启动与重启唯一指南.md
|
||||
|
||||
D:\aaa\aiagent\上传git仓.md 上传git仓
|
||||
|
||||
D:\aaa\aiagent\docs\商业化落地计划.md
|
||||
|
||||
D:\aaa\aiagent\解决缺失能力计划.md 按计划还有哪些要解决的，继续解决
|
||||
|
||||
我自己搭建的http://101.43.95.130:3001/可以吗，账户admin 密码123456 ，里面有项目aiagent，分支rjb_win_dev
|
||||
|
||||
熟悉D:\aaa\aiagent\docs\产品经理目录下内容。看看当前项目D:\aaa\aiagent\下一步干干嘛？
|
||||
|
||||
D:\aaa\aiagent\docs\平台资料.md
|
||||
|
||||
|
||||
D:\aaa\aiagent\docs\登记 Gitea 工单 ，排优先级
|
||||
|
||||
|
||||
将这些需求登记到工单平台（Gitea） D:\aaa\aiagent\docs\平台资料.md
|
||||
|
||||
可参考D:\aaa\aiagent\docs\创建工单总结.md
|
||||
参考文档很有用。现在我按之前的成功方式：用 --data-binary @文件 方式逐个创建工单。
|
||||
## 学生作业管理助手3号可以记住多久的事情
|
||||
|
||||
在 D:\aaa\aiagent\test ，写一个简单的html页面
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
1.如果遇到需要重启服务器可参考D:\aaa\aiagent\(红头)Windows服务器启动与重启唯一指南.md
|
||||
2.git仓资料D:\aaa\aiagent\docs\平台资料.md
|
||||
D:\aaa\aiagent\上传git仓.md 上传git仓
|
||||
3.后台账户密码后台账户admin 密码123456
|
||||
4.项目熟悉D:\aaa\aiagent\docs\
|
||||
5.可以在git仓查看历史D:\aaa\aiagent\上传git仓.md
|
||||
|
||||
D:\aaa\aiagent\docs\商业化落地计划.md
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
瑞来健康项目资料
|
||||
|
||||
后台服务器
|
||||
1.连接D:\cd\tengxunyun\云服务器信息.md
|
||||
2./home/renjianbo/saars/rlz/目录下的项目，启动服务器
|
||||
|
||||
移动端android
|
||||
|
||||
微信小程序
|
||||
|
||||
|
||||
git仓 http://101.43.95.130:3001/admin/rlz (Gitea)，账户 admin 密码123456
|
||||
@@ -0,0 +1,91 @@
|
||||
### ✅ 一步到位的解决方案（按顺序执行）
|
||||
|
||||
#### 1️⃣ 先给你的项目目录，新建项目级配置文件
|
||||
|
||||
在你的项目根目录（比如 `D:\aaa\aiagent`）里，新建 `.claude/settings.json`，把下面的完整配置复制进去：
|
||||
|
||||
json
|
||||
|
||||
```
|
||||
{
|
||||
"permissions": {
|
||||
"allow": [
|
||||
"Read(*)",
|
||||
"Write(*)",
|
||||
"Edit(*)",
|
||||
"Bash(*)",
|
||||
"Bash(pnpm *)",
|
||||
"Bash(node *)",
|
||||
"Bash(npx *)",
|
||||
"Bash(ls *)",
|
||||
"Bash(curl *)",
|
||||
"Bash(python *)",
|
||||
"Bash(pip *)"
|
||||
]
|
||||
},
|
||||
"extraKnownMarketplaces": {
|
||||
"claude-hud": {
|
||||
"source": {
|
||||
"source": "github",
|
||||
"repo": "jarrodwatts/claude-hud"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
⚠️ 注意：文件路径必须是 `你的项目根目录/.claude/settings.json`，少一个层级都不行。
|
||||
|
||||
#### 2️⃣ 彻底重启 Claude Code
|
||||
|
||||
- 关闭所有终端窗口，结束所有 `bun`/`claude` 相关进程。
|
||||
- 重新打开终端，**先进入你的项目目录，再启动开发版**：
|
||||
|
||||
powershell
|
||||
|
||||
```
|
||||
cd D:\aaa\aiagent
|
||||
cd D:\cd\claude-code
|
||||
bun run dev
|
||||
```
|
||||
|
||||
（必须先进入项目目录，再启动，这样开发版才会读取项目下的 `.claude/settings.json`）
|
||||
|
||||
#### 3️⃣ 验证配置是否生效
|
||||
|
||||
在 Claude Code 里输入 `/permissions`，切换到 Allow 标签页：
|
||||
|
||||
- 如果列表里出现了 `Read(*)` / `Write(*)` / `Bash(*)` 这些规则，就说明配置生效了。
|
||||
- 再执行 `ls`/`curl` 这类命令，就不会弹确认了。
|
||||
|
||||
---
|
||||
|
||||
### 🚀 兜底方案：直接用正式版 Claude Code
|
||||
|
||||
开发版的配置加载逻辑很容易出问题，如果你想省麻烦，直接安装官方正式版：
|
||||
|
||||
1. 安装正式版：
|
||||
|
||||
powershell
|
||||
|
||||
```
|
||||
winget install Anthropic.ClaudeCode
|
||||
```
|
||||
|
||||
2. 启动项目：
|
||||
|
||||
powershell
|
||||
|
||||
```
|
||||
cd D:\aaa\aiagent
|
||||
claude
|
||||
```
|
||||
|
||||
3. 正式版会自动加载全局配置，你之前放的 `C:\Users\你的用户名\.claude\settings.json` 就会生效，不用额外配置。
|
||||
|
||||
---
|
||||
|
||||
### 💡 补充说明
|
||||
|
||||
- 配置里的 `Bash(*)` 是开发环境用的，会放行所有 Bash 命令，不推荐在生产环境长期开启。
|
||||
- 如果你想更安全，可以把 `Bash(*)` 换成你实际会用到的命令，比如 `Bash(ls *)`、`Bash(curl *)`、`Bash(python *)` 等。
|
||||
33
docs/Obsidian笔记体系/Projects/claude code/更换云服务器.md
Normal file
33
docs/Obsidian笔记体系/Projects/claude code/更换云服务器.md
Normal file
@@ -0,0 +1,33 @@
|
||||
要跑 Bun + 你这个项目，选云机时重点只有两件事：系统足够新（glibc 别老）、网络和 GitHub 别堵死。
|
||||
|
||||
## 系统怎么选（最重要）
|
||||
|
||||
优先选带这些镜像的机器（任选其一即可）：
|
||||
|
||||
|发行版|说明|
|
||||
|---|---|
|
||||
|Ubuntu 22.04 LTS|文档多、兼容性最好，首推|
|
||||
|Ubuntu 24.04 LTS|更新，一般也没问题|
|
||||
|Debian 12|稳、占用略小|
|
||||
|Rocky Linux 8 / 9、AlmaLinux 8 / 9|习惯 RHEL 系又不想碰 7 时合适|
|
||||
|
||||
不要再用 CentOS 7 / 过老的 Amazon Linux 1 这类 glibc 太老的镜像，否则又会遇到你现在的 `GLIBC_2.18` 问题。
|
||||
|
||||
架构选 x86_64（amd64） 最省事（和你下的 `bun-linux-x64.zip` 一致）。若买 ARM（aarch64），要改用 Bun 的 linux aarch64 包，别混用 x64 包。
|
||||
|
||||
## 哪家云「最好」
|
||||
|
||||
没有绝对最好，按你在国内还是海外、预算、是否已有账号选即可，例如：
|
||||
|
||||
- 国内：阿里云、腾讯云、华为云等，选上面任一 Ubuntu 22.04 即可；在意 GitHub 速度可考虑换源或走代理。
|
||||
- 海外：AWS、GCP、Azure、DigitalOcean、Linode 等，同样 Ubuntu 22.04 最省心。
|
||||
|
||||
## 配置建议（跑 CLI 项目）
|
||||
|
||||
- 内存：至少 2 GB；经常开大仓库可适当 4 GB。
|
||||
- 磁盘：40 GB+ 更从容（依赖、构建产物、日志）。
|
||||
- 带宽：按你所在网络选，能稳定访问 GitHub / npm 源比单纯高 CPU 更重要。
|
||||
|
||||
---
|
||||
|
||||
一句话：在国内云上开一台 Ubuntu 22.04 LTS、2C4G、x86_64，再按之前的 `wget` 装 Bun，通常是最顺的组合。若你告诉我预算（月费）和云厂商（已有哪家账号），我可以帮你缩到具体套餐档位。
|
||||
76
docs/Obsidian笔记体系/Projects/claude code/模型上下文限制问题.md
Normal file
76
docs/Obsidian笔记体系/Projects/claude code/模型上下文限制问题.md
Normal file
@@ -0,0 +1,76 @@
|
||||
模型上下文限制：您使用的模型最大支持 102,400 tokens，但当前请求使用了 104,297 tokens，超出了 1,897 tokens。
|
||||
|
||||
详细组成：
|
||||
- 消息部分：72,297 tokens（对话历史、文件内容、工具输出等）
|
||||
- 补全部分：32,000 tokens（模型生成的最大长度）
|
||||
|
||||
🛠️ 解决方案
|
||||
|
||||
1. 立即解决方案（推荐）
|
||||
|
||||
- 开始新对话：当前对话历史太长，最简单的方法是重新启动Claude Code或开始新对话
|
||||
- 清除上下文：如果Claude Code有清除历史的功能，使用它
|
||||
|
||||
2. 配置调整
|
||||
|
||||
- 检查当前模型：错误显示模型限制为102,400 tokens，这可能是旧版模型
|
||||
# 查看当前使用的模型
|
||||
echo $ANTHROPIC_MODEL # 或检查配置
|
||||
- 切换到更高版本模型：
|
||||
- Claude 3.5 Sonnet/Opus：200K上下文
|
||||
- Claude 3.7 Sonnet：200K上下文
|
||||
- 在环境变量中设置：
|
||||
$env:ANTHROPIC_MODEL="claude-3-5-sonnet-20241022"
|
||||
|
||||
3. 减少上下文使用
|
||||
|
||||
- 减少文件读取：避免一次性读取太多文件内容
|
||||
- 精简工具输出：减少Bash命令、文件搜索的输出内容
|
||||
- 分批处理：将大任务分解为多个小任务
|
||||
|
||||
4. 技术调整（高级）
|
||||
|
||||
- 调整max_tokens参数：减少模型生成的最大token数
|
||||
- 启用上下文压缩：如果Claude Code支持，启用对话压缩功能
|
||||
- 使用更小模型：暂时切换到Haiku等轻量模型处理简单任务
|
||||
|
||||
📝 具体操作步骤
|
||||
|
||||
方法A：快速重启
|
||||
|
||||
1. 退出当前Claude Code（Ctrl+C）
|
||||
2. 重新启动：bun run dev
|
||||
3. 开始新的对话
|
||||
|
||||
方法B：模型升级
|
||||
|
||||
4. 设置环境变量：
|
||||
$env:ANTHROPIC_MODEL="claude-3-5-sonnet-20241022"
|
||||
$env:ANTHROPIC_API_KEY="您的密钥"
|
||||
5. 重启Claude Code
|
||||
|
||||
方法C：清理配置
|
||||
|
||||
检查.claude/目录下的配置文件，确保没有限制性设置。
|
||||
|
||||
🔧 预防措施
|
||||
|
||||
6. 监控上下文使用：注意长时间对话的积累
|
||||
7. 定期重启：处理复杂任务后重启对话
|
||||
8. 使用合适模型：根据任务复杂度选择模型
|
||||
9. 配置环境变量：
|
||||
# 设置代理（如果需要）
|
||||
$env:HTTP_PROXY="http://127.0.0.1:1080"
|
||||
$env:HTTPS_PROXY="http://127.0.0.1:1080"
|
||||
|
||||
# 设置模型
|
||||
$env:ANTHROPIC_MODEL="claude-3-5-sonnet-20241022"
|
||||
|
||||
❓ 如果问题依旧
|
||||
|
||||
10. 检查API密钥权限：确保账户有权限使用所选模型
|
||||
11. 查看网络连接：确保能正常访问Anthropic API
|
||||
12. 查看Claude Code日志：可能有更多错误信息
|
||||
13. 参考项目文档：查看README.md和BUILD_GUIDE.md
|
||||
|
||||
建议先尝试方法A（重启对话），这通常能立即解决问题。如果频繁出现此错误，再考虑升级模型或调整配置。
|
||||
213
docs/Obsidian笔记体系/Projects/claude code/自主agent改造计划方案.md
Normal file
213
docs/Obsidian笔记体系/Projects/claude code/自主agent改造计划方案.md
Normal file
@@ -0,0 +1,213 @@
|
||||
---
|
||||
从工作流引擎到自主 AI Agent：改造方案
|
||||
|
||||
核心思路：不要重构，要"寄生式"生长
|
||||
|
||||
现有引擎 5788 行，WorkflowEditor.vue 9140 行——不要重构它们。而是寄生在已有的 ToolRegistry、LLM Service、Memory Service
|
||||
之上，新建一个独立的 Agent Runtime。
|
||||
|
||||
---
|
||||
第一步：构建 Agent Runtime 内核（1 周）
|
||||
|
||||
新建 backend/app/agent_runtime/ 包：
|
||||
|
||||
backend/app/agent_runtime/
|
||||
├── __init__.py
|
||||
├── core.py # Agent 主循环
|
||||
├── context.py # Agent 上下文（会话状态）
|
||||
├── memory.py # 记忆管理（连接已有记忆服务）
|
||||
├── tool_manager.py # 工具选择与执行（连接已有 ToolRegistry）
|
||||
└── schemas.py # Agent 配置 Schema
|
||||
|
||||
核心循环 (core.py)：
|
||||
|
||||
class AgentRuntime:
|
||||
"""
|
||||
自主 Agent 循环（ReAct）
|
||||
|
||||
loop:
|
||||
1. LLM 思考 → 返回文本或工具调用
|
||||
2. 如果返回文本 → 结束，返回最终回答
|
||||
3. 如果调用工具 → 执行工具 → 结果追加到 messages → 回到 1
|
||||
4. 超过 max_iterations → 强制结束
|
||||
"""
|
||||
|
||||
async def run(self, user_input: str) -> AgentResult:
|
||||
while self.iteration < self.max_iterations:
|
||||
response = await self.llm.chat(messages, tools)
|
||||
if response.has_tool_calls:
|
||||
for tool_call in response.tool_calls:
|
||||
result = tool_registry.execute(tool_call)
|
||||
messages.append(tool_result_message)
|
||||
else:
|
||||
return AgentResult(text=response.content)
|
||||
return AgentResult(text="已达最大迭代次数", truncated=True)
|
||||
|
||||
关键设计点：
|
||||
|
||||
┌────────────┬─────────────────────────────────────────────────┬───────────────────────┐
|
||||
│ 组件 │ 复用什么 │ 新写什么 │
|
||||
├────────────┼─────────────────────────────────────────────────┼───────────────────────┤
|
||||
│ LLM 调用 │ llm_service.call_openai_with_tools() 已有 ReAct │ 不用写 │
|
||||
├────────────┼─────────────────────────────────────────────────┼───────────────────────┤
|
||||
│ 工具执行 │ ToolRegistry.get_tool_function() │ 不用写 │
|
||||
├────────────┼─────────────────────────────────────────────────┼───────────────────────┤
|
||||
│ 记忆存储 │ persistent_memory_service.py │ 记忆检索 + 自动压缩 │
|
||||
├────────────┼─────────────────────────────────────────────────┼───────────────────────┤
|
||||
│ 系统提示词 │ — │ Agent 人格/指令系统 │
|
||||
├────────────┼─────────────────────────────────────────────────┼───────────────────────┤
|
||||
│ 会话管理 │ — │ 状态保持 + 多轮上下文 │
|
||||
└────────────┴─────────────────────────────────────────────────┴───────────────────────┘
|
||||
|
||||
工作量：约 300 行代码。已有轮子都在，只要串起来。
|
||||
|
||||
---
|
||||
第二步：让 Agent Runtime 能用上已有工具（3 天）
|
||||
|
||||
现有 ToolRegistry 有 20+ 内置工具，但只通过 llm_service.py 的 _execute_tool 私有方法调用。需要：
|
||||
|
||||
# 新增 agent_runtime/tool_manager.py
|
||||
class AgentToolManager:
|
||||
def __init__(self, tool_registry):
|
||||
self.registry = tool_registry
|
||||
|
||||
def get_tools_for_llm(self) -> list:
|
||||
# 把 ToolRegistry 的 schema 转为 OpenAI tool format
|
||||
return self.registry.get_all_tool_schemas()
|
||||
|
||||
async def execute(self, name: str, args: dict) -> str:
|
||||
func = self.registry.get_tool_function(name)
|
||||
if func is None:
|
||||
return f"错误：工具 {name} 不存在"
|
||||
result = await func(**args) # 已有，直接复用
|
||||
return str(result)
|
||||
|
||||
注意：现有 _execute_tool 在 llm_service.py 中，需要提取成公共方法或让 ToolManager 直接调用已有实现。
|
||||
|
||||
---
|
||||
第三步：接入记忆系统（3 天）
|
||||
|
||||
现有记忆系统已经可以读写用户画像和对话历史（persistent_memory_service.py），但只在 Cache 节点中被动使用。
|
||||
|
||||
需要：
|
||||
|
||||
# agent_runtime/memory.py
|
||||
class AgentMemory:
|
||||
"""
|
||||
分层记忆：
|
||||
- 工作记忆：当前会话的 messages
|
||||
- 长期记忆：从 DB/Redis 加载的历史画像 + 重要事实
|
||||
- 工具记忆：哪些工具调用成功/失败（辅助 LLM 决策）
|
||||
"""
|
||||
|
||||
async def load_context(self, user_id: str) -> str:
|
||||
# 从 persistent_memory_service 加载用户画像
|
||||
profile = get_user_profile(user_id)
|
||||
# 从数据库加载最近对话摘要
|
||||
history = get_conversation_summary(user_id)
|
||||
return f"用户画像：{profile}\n历史记录：{history}"
|
||||
|
||||
async def save(self, messages: list):
|
||||
# 自动总结关键信息写入长期记忆
|
||||
summary = await self.llm.summarize(messages)
|
||||
save_user_profile(user_id, summary)
|
||||
|
||||
---
|
||||
第四步：在现有工作流中启用 Agent 节点（3 天）
|
||||
|
||||
在 workflow_engine.py 的 execute_node 中新增 agent 类型：
|
||||
|
||||
# 现有 5788 行引擎只需加一个分支
|
||||
elif node_type == 'agent':
|
||||
# 初始化 Agent Runtime
|
||||
runtime = AgentRuntime(
|
||||
system_prompt=node_data.get('system_prompt'),
|
||||
tools=node_data.get('tools', []), # 可选，默认全部
|
||||
memory_enabled=node_data.get('memory', True),
|
||||
)
|
||||
result = await runtime.run(input_data.get('query', ''))
|
||||
|
||||
这样不用动现有任何节点，用户可以在工作流中拖一个 Agent 节点，它就能：
|
||||
1. 自动 ReAct 循环
|
||||
2. 调用任意内置工具
|
||||
3. 使用长期记忆
|
||||
4. 自我纠错
|
||||
|
||||
---
|
||||
第五步：独立 Agent 运行模式（1 周）
|
||||
|
||||
不依赖工作流 DAG，可以直接启动 Agent：
|
||||
|
||||
POST /api/v1/agents/{id}/chat
|
||||
{"message": "帮我写一个Python脚本读取日志"}
|
||||
|
||||
后端：
|
||||
runtime = AgentRuntime(agent_config)
|
||||
result = await runtime.run(message)
|
||||
return result
|
||||
|
||||
前端可以加一个聊天界面（类似 ChatGPT）：
|
||||
- 已有 AgentChatPreview.vue 可以改造
|
||||
- 复用现有 Agents.vue 的列表和配置
|
||||
|
||||
---
|
||||
第六步：多智能体编排（2 周）
|
||||
|
||||
# agent_runtime/orchestrator.py
|
||||
class AgentOrchestrator:
|
||||
"""
|
||||
多 Agent 协作模式：
|
||||
|
||||
1. 路由模式：用户问题 → Router Agent → 分发到子 Agent
|
||||
2. 顺序模式：Agent A 输出 → Agent B 输入
|
||||
3. 辩论模式：多个 Agent 独立回答 → 汇总
|
||||
"""
|
||||
|
||||
async def route(self, question: str) -> str:
|
||||
# Router Agent 判断应该用哪个 Specialist Agent
|
||||
specialist = await self.router_agent.choose(question)
|
||||
return await specialist.run(question)
|
||||
|
||||
---
|
||||
整体路线图
|
||||
|
||||
┌──────┬────────────────────────┬──────┬────────────┐
|
||||
│ 阶段 │ 内容 │ 时间 │ 前提 │
|
||||
├──────┼────────────────────────┼──────┼────────────┤
|
||||
│ P0 │ Agent Runtime 内核 │ 1 周 │ 无，纯新增 │
|
||||
├──────┼────────────────────────┼──────┼────────────┤
|
||||
│ P0 │ 工具接入 │ 3 天 │ P0 完成 │
|
||||
├──────┼────────────────────────┼──────┼────────────┤
|
||||
│ P1 │ 记忆接入 │ 3 天 │ P0 完成 │
|
||||
├──────┼────────────────────────┼──────┼────────────┤
|
||||
│ P1 │ Agent 节点（工作流内） │ 3 天 │ P0+P1 完成 │
|
||||
├──────┼────────────────────────┼──────┼────────────┤
|
||||
│ P2 │ 独立 Agent 聊天模式 │ 1 周 │ P0+P1 完成 │
|
||||
├──────┼────────────────────────┼──────┼────────────┤
|
||||
│ P3 │ 多 Agent 编排 │ 2 周 │ P0-P2 完成 │
|
||||
├──────┼────────────────────────┼──────┼────────────┤
|
||||
│ P3 │ Agent 工作台/监控 │ 1 周 │ P0-P2 完成 │
|
||||
└──────┴────────────────────────┴──────┴────────────┘
|
||||
|
||||
---
|
||||
为什么这个方案可行
|
||||
|
||||
你代码库中 关键能力已经就绪：
|
||||
|
||||
┌─────────────────────────┬─────────────────────────────────────┬──────────────────┬────────────────┐
|
||||
│ 已有能力 │ 位置 │ 当前用途 │ 新计划用途 │
|
||||
├─────────────────────────┼─────────────────────────────────────┼──────────────────┼────────────────┤
|
||||
│ ReAct 循环 │ llm_service.py:646 │ LLM 节点单次调用 │ Agent 核心循环 │
|
||||
├─────────────────────────┼─────────────────────────────────────┼──────────────────┼────────────────┤
|
||||
│ ToolRegistry + 20+ 工具 │ tool_registry.py + builtin_tools.py │ 工作流内使用 │ Agent 自主调用 │
|
||||
├─────────────────────────┼─────────────────────────────────────┼──────────────────┼────────────────┤
|
||||
│ 持久化记忆 │ persistent_memory_service.py │ Cache 节点 │ 长期记忆层 │
|
||||
├─────────────────────────┼─────────────────────────────────────┼──────────────────┼────────────────┤
|
||||
│ 对话历史注入 │ workflow_engine.py:986 │ LLM 节点 │ Agent 上下文 │
|
||||
├─────────────────────────┼─────────────────────────────────────┼──────────────────┼────────────────┤
|
||||
│ Agent 配置 │ models/agent.py │ 工作流包装 │ Agent 本体配置 │
|
||||
└─────────────────────────┴─────────────────────────────────────┴──────────────────┴────────────────┘
|
||||
|
||||
新增代码控制在 1500 行以内，不动现有 5788 行的引擎和 9140 行的编辑器。
|
||||
|
||||
需要我从第一步的 Agent Runtime 核心代码开始写吗？
|
||||
104
docs/Obsidian笔记体系/Projects/瑞来兹软件公司组织架构/产品经理/产品经理角色文档.md
Normal file
104
docs/Obsidian笔记体系/Projects/瑞来兹软件公司组织架构/产品经理/产品经理角色文档.md
Normal file
@@ -0,0 +1,104 @@
|
||||
# 产品经理
|
||||
|
||||
> 所属公司：瑞来兹软件技术有限公司
|
||||
> 更新日期：2026-05-04
|
||||
|
||||
---
|
||||
|
||||
## 一、角色定义
|
||||
|
||||
产品经理（Product Manager）是产品的所有者，负责从需求发现到产品上线的全生命周期管理，在用户价值与商业价值之间寻找最优解。
|
||||
|
||||
---
|
||||
|
||||
## 二、主要职责
|
||||
|
||||
### 2.1 需求管理
|
||||
- 收集并分析用户反馈、业务需求、市场趋势
|
||||
- 撰写 BRD（商业需求文档）和 PRD（产品需求文档）
|
||||
- 维护产品 Backlog，持续进行需求优先级排序
|
||||
- 组织需求评审会，协同技术、设计、测试对齐需求
|
||||
|
||||
### 2.2 产品规划
|
||||
- 制定产品路线图（Roadmap），明确版本迭代节奏
|
||||
- 定义产品核心指标（KPI/OKR），跟踪产品数据表现
|
||||
- 竞品分析与市场调研，输出竞品分析报告
|
||||
- 参与公司战略规划，对齐产品方向与业务目标
|
||||
|
||||
### 2.3 功能设计
|
||||
- 输出产品原型（低保真/高保真）、交互流程图
|
||||
- 编写用户故事（User Story）和验收标准（AC）
|
||||
- 与 UX/UI 设计师协作完成界面设计
|
||||
- 定义功能边界、异常状态、权限模型
|
||||
|
||||
### 2.4 项目推进
|
||||
- 参与 Sprint Planning、每日站会、Sprint Review
|
||||
- 在开发过程中澄清需求细节，及时调整方案
|
||||
- 组织 UAT（用户验收测试），确认上线条件
|
||||
- 版本发布后撰写 Release Notes，组织功能宣讲
|
||||
|
||||
### 2.5 数据分析与迭代
|
||||
- 上线后跟踪产品数据（DAU、留存率、转化率等）
|
||||
- 通过 A/B 测试验证功能假设
|
||||
- 收集用户反馈，驱动下一轮产品迭代
|
||||
- 定期输出产品月报/季报
|
||||
|
||||
---
|
||||
|
||||
## 三、常用平台与工具
|
||||
|
||||
| 分类 | 工具 | 用途 |
|
||||
|------|------|------|
|
||||
| **原型设计** | Axure RP | 高保真原型、复杂交互 |
|
||||
| | Figma | UI 协作设计、原型演示 |
|
||||
| | 墨刀（Mockplus） | 快速原型、团队协作 |
|
||||
| | Sketch | Mac 端 UI 设计 |
|
||||
| **项目管理** | Jira | 需求跟踪、Sprint 管理 |
|
||||
| | 禅道 | 国产项目管理、Bug 跟踪 |
|
||||
| | Trello | 轻量看板管理 |
|
||||
| | Notion | 文档协作、知识库 |
|
||||
| | Confluence | 需求文档 Wiki |
|
||||
| | PingCode | 国产研发管理平台 |
|
||||
| **文档协作** | 飞书文档 | 内部协作与文档 |
|
||||
| | 语雀 | 知识库与文档 |
|
||||
| | 石墨文档 | 在线协同编辑 |
|
||||
| | Google Docs | 国际团队协作 |
|
||||
| **数据分析** | 神策数据 | 用户行为分析 |
|
||||
| | GrowingIO | 无埋点数据分析 |
|
||||
| | Google Analytics | Web 流量分析 |
|
||||
| | 友盟+ | 移动端数据统计 |
|
||||
| | Metabase / Superset | BI 自助分析 |
|
||||
| **沟通协作** | 飞书 / 钉钉 / 企业微信 | 即时通讯 |
|
||||
| | Slack | 国际团队通讯 |
|
||||
| | Zoom / 腾讯会议 | 视频会议 |
|
||||
| **思维导图** | XMind | 需求梳理、功能拆解 |
|
||||
| | ProcessOn | 流程图、脑图在线 |
|
||||
| | Draw.io | 架构图、流程图 |
|
||||
|
||||
---
|
||||
|
||||
## 四、能力模型
|
||||
|
||||
| 能力 | 要求 |
|
||||
|------|------|
|
||||
| 需求洞察 | 能从模糊业务诉求中提炼可执行需求 |
|
||||
| 逻辑思维 | 严谨的功能边界与异常流梳理 |
|
||||
| 数据分析 | SQL 查询、指标体系搭建、A/B 实验设计 |
|
||||
| 沟通协调 | 跨部门（技术/设计/运营/销售）高效沟通 |
|
||||
| 技术理解 | 了解前后端基础、API 概念、数据库基础 |
|
||||
| 商业思维 | 理解商业模式、ROI 评估、定价策略 |
|
||||
|
||||
---
|
||||
|
||||
## 五、产出物清单
|
||||
|
||||
| 产出物 | 交付节点 |
|
||||
|--------|----------|
|
||||
| 竞品分析报告 | 产品立项前 |
|
||||
| BRD（商业需求文档） | 立项阶段 |
|
||||
| PRD（产品需求文档） | 需求评审前 |
|
||||
| 产品原型 | 需求评审前 |
|
||||
| 用户故事地图 | Sprint 规划前 |
|
||||
| 产品路线图 | 季度/年度规划 |
|
||||
| 产品数据月报 | 每月 |
|
||||
| Release Notes | 每个版本发布 |
|
||||
153
docs/Obsidian笔记体系/Projects/瑞来兹软件公司组织架构/开发/开发角色文档.md
Normal file
153
docs/Obsidian笔记体系/Projects/瑞来兹软件公司组织架构/开发/开发角色文档.md
Normal file
@@ -0,0 +1,153 @@
|
||||
# 开发
|
||||
|
||||
> 所属公司：瑞来兹软件技术有限公司
|
||||
> 更新日期：2026-05-04
|
||||
|
||||
---
|
||||
|
||||
## 一、角色定义
|
||||
|
||||
开发工程师（Developer）是产品的建造者，负责将需求和设计转化为可运行的软件系统，涵盖前端、后端、移动端、数据等多个方向。
|
||||
|
||||
---
|
||||
|
||||
## 二、主要职责
|
||||
|
||||
### 2.1 编码实现
|
||||
- 根据 PRD 和技术方案完成功能开发
|
||||
- 编写高质量、可维护、可测试的代码
|
||||
- 遵循编码规范和团队约定的设计模式
|
||||
- 实现 API 接口、数据库操作、业务逻辑
|
||||
- 前端页面还原、交互实现、状态管理
|
||||
|
||||
### 2.2 代码质量
|
||||
- 编写单元测试（Jest/JUnit/pytest），保证核心逻辑覆盖率
|
||||
- 代码自测，确保提测质量
|
||||
- 参与 Code Review，互相审查代码质量
|
||||
- 使用 SonarQube / ESLint 等工具确保代码规范
|
||||
- 重构遗留代码，消除技术债务
|
||||
|
||||
### 2.3 技术方案
|
||||
- 参与技术方案评审，评估实现可行性
|
||||
- 编写模块级别的详细设计文档
|
||||
- 评估需求实现工时（Story Point / 人天）
|
||||
- 对复杂功能进行技术预研（Spike）
|
||||
|
||||
### 2.4 协作与交付
|
||||
- 参与 Sprint 规划、每日站会、评审会
|
||||
- 与测试工程师协作定位和修复 Bug
|
||||
- 与产品经理澄清需求实现细节
|
||||
- 配合运维完成服务上线、灰度发布
|
||||
- 编写上线 Checklist 和技术 Release Notes
|
||||
|
||||
### 2.5 学习与成长
|
||||
- 持续学习新技术、新框架
|
||||
- 参与技术分享，沉淀团队知识
|
||||
- 阅读优秀开源项目源码
|
||||
- 初级工程师接受高级/架构师指导
|
||||
|
||||
---
|
||||
|
||||
## 三、常用平台与工具
|
||||
|
||||
### 3.1 后端开发
|
||||
|
||||
| 分类 | 工具 | 用途 |
|
||||
|------|------|------|
|
||||
| **语言与框架** | Go + Gin / Kratos | 微服务开发 |
|
||||
| | Java + Spring Boot / Spring Cloud | 企业级后端 |
|
||||
| | Python + FastAPI / Django | 快速开发 / AI 服务 |
|
||||
| | Node.js + Nest.js / Express | BFF 层 / 轻量服务 |
|
||||
| | Rust | 高性能系统 |
|
||||
| **数据库** | MySQL / PostgreSQL | 关系型数据 |
|
||||
| | Redis | 缓存、队列、锁 |
|
||||
| | MongoDB | 文档存储 |
|
||||
| | Elasticsearch | 全文搜索 |
|
||||
| **消息队列** | Kafka / RocketMQ / RabbitMQ | 异步解耦 |
|
||||
| **IDE** | VS Code / IntelliJ IDEA / GoLand | 开发环境 |
|
||||
| **API 工具** | Postman / Apifox / Apipost | 接口调试 |
|
||||
| | Swagger / OpenAPI | API 文档 |
|
||||
|
||||
### 3.2 前端开发
|
||||
|
||||
| 分类 | 工具 | 用途 |
|
||||
|------|------|------|
|
||||
| **框架** | React + Next.js | Web 前端 |
|
||||
| | Vue 3 + Nuxt | Web 前端 |
|
||||
| | TypeScript | 类型安全 |
|
||||
| **UI 库** | Ant Design / Element Plus | 中后台组件 |
|
||||
| | Tailwind CSS | 原子化 CSS |
|
||||
| | Shadcn/ui | 可定制组件 |
|
||||
| **构建工具** | Vite / Webpack / Turbopack | 构建打包 |
|
||||
| **状态管理** | Zustand / Pinia / Redux | 状态管理 |
|
||||
| **测试** | Vitest / Playwright / Cypress | 单元/端到端测试 |
|
||||
| **IDE** | VS Code / Cursor | 开发环境 |
|
||||
| **调试** | Chrome DevTools / React DevTools | 调试工具 |
|
||||
|
||||
### 3.3 移动端开发
|
||||
|
||||
| 分类 | 工具 | 用途 |
|
||||
|------|------|------|
|
||||
| **平台** | Swift + SwiftUI（iOS） | iOS 原生 |
|
||||
| | Kotlin + Jetpack Compose（Android） | Android 原生 |
|
||||
| | Flutter / React Native | 跨端开发 |
|
||||
| **测试** | XCTest（iOS）/ Espresso（Android） | 单元/UI 测试 |
|
||||
| **分发** | TestFlight / Firebase App Distribution | 测试分发 |
|
||||
| **性能** | Instruments（iOS）/ Android Profiler | 性能分析 |
|
||||
|
||||
### 3.4 通用工具
|
||||
|
||||
| 工具 | 用途 |
|
||||
|------|------|
|
||||
| Git + GitHub / GitLab / Gitee | 版本控制 |
|
||||
| Docker | 容器化开发环境 |
|
||||
| VS Code / JetBrains 系列 | IDE |
|
||||
| Tmux / iTerm2 / Windows Terminal | 终端 |
|
||||
| Figma（查看模式） | 设计稿查看 |
|
||||
| Raycast / Alfred | 效率工具 |
|
||||
|
||||
---
|
||||
|
||||
## 四、开发流程
|
||||
|
||||
```
|
||||
需求理解 → 技术方案 → 编码实现 → 自测 → 代码评审 → 提测 → 修复Bug → 上线
|
||||
│ │ │ │ │ │ │ │
|
||||
▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
|
||||
PRD阅读 设计文档 分支开发 单元测试 PR/MR 提测单 Bug修复 发布清单
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 五、能力模型
|
||||
|
||||
| 级别 | 能力要求 |
|
||||
|------|----------|
|
||||
| **初级** | 独立完成明确需求的功能开发、Bug 修复 |
|
||||
| **中级** | 独立负责模块设计与实现、指导初级工程师 |
|
||||
| **高级** | 主导子系统设计、跨模块优化、Code Review 把控 |
|
||||
| **资深** | 领域专家、技术难题攻关、架构设计参与 |
|
||||
|
||||
| 通用能力 | 要求 |
|
||||
|----------|------|
|
||||
| 编程语言 | 精通至少一门语言及其生态 |
|
||||
| 数据结构与算法 | 常见数据结构、算法复杂度分析 |
|
||||
| 设计模式 | 常用 23 种模式，能合理应用 |
|
||||
| 数据库 | SQL 编写、索引优化、慢查询分析 |
|
||||
| Linux | 命令行操作、脚本编写、服务部署 |
|
||||
| Git | 分支管理、冲突解决、Git Flow |
|
||||
| 调试能力 | 日志分析、断点调试、性能 Profiling |
|
||||
|
||||
---
|
||||
|
||||
## 六、产出物清单
|
||||
|
||||
| 产出物 | 交付节点 |
|
||||
|--------|----------|
|
||||
| 技术方案/详细设计 | 编码前 |
|
||||
| 功能代码（含单测） | Sprint 结束 |
|
||||
| API 接口文档更新 | 接口变更时 |
|
||||
| 自测报告 | 提测时 |
|
||||
| Code Review 记录 | 每个 PR/MR |
|
||||
| 上线 Checklist | 发布前 |
|
||||
| 技术分享文档 | 不定期 |
|
||||
130
docs/Obsidian笔记体系/Projects/瑞来兹软件公司组织架构/架构师/架构师角色文档.md
Normal file
130
docs/Obsidian笔记体系/Projects/瑞来兹软件公司组织架构/架构师/架构师角色文档.md
Normal file
@@ -0,0 +1,130 @@
|
||||
# 架构师
|
||||
|
||||
> 所属公司：瑞来兹软件技术有限公司
|
||||
> 更新日期：2026-05-04
|
||||
|
||||
---
|
||||
|
||||
## 一、角色定义
|
||||
|
||||
架构师（Architect）是技术方向的掌舵者，负责系统架构设计、技术选型、非功能需求保障（性能/安全/可扩展性），并在关键决策上提供技术判断力。按领域可细分为：系统架构师、应用架构师、数据架构师、安全架构师、解决方案架构师。
|
||||
|
||||
---
|
||||
|
||||
## 二、主要职责
|
||||
|
||||
### 2.1 架构设计
|
||||
- 设计系统整体架构（微服务/单体/混合），产出架构图
|
||||
- 定义模块边界、服务拆分、接口契约（API 设计）
|
||||
- 制定技术选型标准（语言、框架、中间件、数据库）
|
||||
- 设计数据架构：数据模型、分库分表策略、读写分离
|
||||
- 设计部署架构：K8s 集群规划、网络拓扑、容灾方案
|
||||
|
||||
### 2.2 技术规范
|
||||
- 制定编码规范、分支管理策略（Git Flow / Trunk-Based）
|
||||
- 定义 API 设计规范（RESTful / GraphQL / gRPC）
|
||||
- 建立技术雷达（Tech Radar），跟踪新兴技术
|
||||
- 制定安全编码规范（OWASP Top 10 防护）
|
||||
- 编写架构决策记录（ADR）
|
||||
|
||||
### 2.3 非功能需求保障
|
||||
- 性能优化：系统吞吐量、响应时间、并发能力
|
||||
- 高可用设计：多活/主备、故障转移、降级熔断
|
||||
- 安全架构：认证授权（OAuth2.0/OIDC）、数据加密、审计日志
|
||||
- 可扩展性：水平扩展策略、CQRS、事件驱动
|
||||
- 可观测性：日志、指标、链路追踪（OpenTelemetry）
|
||||
|
||||
### 2.4 技术评审与治理
|
||||
- 主持技术方案评审会，评估方案可行性
|
||||
- 核心模块代码审查，确保架构一致性
|
||||
- 识别技术债务，制定偿还计划
|
||||
- 参与技术委员会，制定长期技术战略
|
||||
|
||||
### 2.5 团队赋能
|
||||
- 指导高级开发工程师，提升团队技术水位
|
||||
- 定期组织技术分享会（Tech Talk）
|
||||
- 编写架构文档，降低系统认知负荷
|
||||
- 帮助团队攻克技术难题（攻关）
|
||||
|
||||
---
|
||||
|
||||
## 三、常用平台与工具
|
||||
|
||||
| 分类 | 工具 | 用途 |
|
||||
|------|------|------|
|
||||
| **架构设计** | Draw.io | 架构图、流程图、网络拓扑 |
|
||||
| | PlantUML | 代码生成 UML 图 |
|
||||
| | C4 Model / Structurizr | 分层架构可视化 |
|
||||
| | Excalidraw | 手绘风格架构草图 |
|
||||
| | ArchiMate | 企业架构建模 |
|
||||
| **技术文档** | Confluence / Notion | 架构文档协作 |
|
||||
| | ADR Tools | 架构决策记录管理 |
|
||||
| | Markdown + Git | 轻量文档版本管理 |
|
||||
| **中间件与基础设施** | Kubernetes (K8s) | 容器编排 |
|
||||
| | Istio / Linkerd | 服务网格 |
|
||||
| | Nacos / Consul | 服务注册与配置 |
|
||||
| | Redis | 缓存 / 分布式锁 |
|
||||
| | Kafka / RocketMQ / RabbitMQ | 消息队列 |
|
||||
| | Nginx / APISIX / Kong | API 网关 |
|
||||
| | Elasticsearch | 搜索与分析引擎 |
|
||||
| **数据库** | MySQL / PostgreSQL | 关系型数据库 |
|
||||
| | MongoDB | 文档型 NoSQL |
|
||||
| | TiDB / CockroachDB | 分布式 SQL |
|
||||
| | ClickHouse / Doris | OLAP 分析 |
|
||||
| **监控与可观测** | Prometheus + Grafana | 监控与可视化 |
|
||||
| | ELK（Elasticsearch + Logstash + Kibana） | 日志管理 |
|
||||
| | SkyWalking / Jaeger / Zipkin | 链路追踪 |
|
||||
| | Sentry | 错误追踪 |
|
||||
| **CI/CD** | Jenkins / GitLab CI / GitHub Actions | 流水线 |
|
||||
| | ArgoCD | GitOps 部署 |
|
||||
| | Docker / Containerd | 容器化 |
|
||||
| **安全** | SonarQube | 代码安全扫描 |
|
||||
| | Vault | 密钥管理 |
|
||||
| | OWASP ZAP | 安全测试 |
|
||||
|
||||
---
|
||||
|
||||
## 四、架构设计原则
|
||||
|
||||
```
|
||||
1. KISS（Keep It Simple, Stupid）—— 简单优于复杂
|
||||
2. YAGNI（You Aren't Gonna Need It）—— 不为未来过度设计
|
||||
3. 高内聚低耦合 —— 模块内紧密关联，模块间松散依赖
|
||||
4. 关注点分离（Separation of Concerns）
|
||||
5. 面向失败设计（Design for Failure）
|
||||
6. 无状态优先 —— 有状态服务需特殊设计
|
||||
7. 数据一致性权衡 —— CAP 取舍、最终一致性
|
||||
8. API First —— 先定义接口，再实现
|
||||
9. 12-Factor App —— 云原生应用方法论
|
||||
10. 安全左移（Shift Left on Security）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 五、能力模型
|
||||
|
||||
| 能力 | 要求 |
|
||||
|------|------|
|
||||
| 系统设计 | 分布式系统、微服务、领域驱动设计（DDD） |
|
||||
| 技术广度 | 多语言/多框架/多数据库经验 |
|
||||
| 抽象思维 | 从业务需求抽象架构模型 |
|
||||
| 决策能力 | 技术选型与权衡（Trade-off）分析 |
|
||||
| 沟通表达 | 能用图/文档清晰传达架构意图 |
|
||||
| 业务理解 | 理解业务战略，支撑业务扩展 |
|
||||
| 领导力 | 技术驱动，不依赖职级 |
|
||||
|
||||
---
|
||||
|
||||
## 六、产出物清单
|
||||
|
||||
| 产出物 | 交付节点 |
|
||||
|--------|----------|
|
||||
| 系统架构设计文档 | 项目启动阶段 |
|
||||
| 技术选型报告 | 方案评审 |
|
||||
| API 设计规范 | 编码前 |
|
||||
| 数据库 ER 图与表设计 | 编码前 |
|
||||
| 部署架构图 | 上线前 |
|
||||
| 架构评审记录 | 每次评审 |
|
||||
| ADR（架构决策记录） | 关键决策时 |
|
||||
| 性能压测报告 | 上线前 |
|
||||
| 技术雷达 | 季度 |
|
||||
162
docs/Obsidian笔记体系/Projects/瑞来兹软件公司组织架构/测试/测试角色文档.md
Normal file
162
docs/Obsidian笔记体系/Projects/瑞来兹软件公司组织架构/测试/测试角色文档.md
Normal file
@@ -0,0 +1,162 @@
|
||||
# 测试
|
||||
|
||||
> 所属公司：瑞来兹软件技术有限公司
|
||||
> 更新日期：2026-05-04
|
||||
|
||||
---
|
||||
|
||||
## 一、角色定义
|
||||
|
||||
测试工程师（QA Engineer）是产品质量的守门员，通过功能测试、自动化测试、性能测试、安全测试等手段，保障软件交付质量，降低线上故障风险。
|
||||
|
||||
---
|
||||
|
||||
## 二、主要职责
|
||||
|
||||
### 2.1 测试规划
|
||||
- 参与需求评审，从测试角度提出可测性建议
|
||||
- 编写测试计划，明确测试范围、策略、资源
|
||||
- 设计测试用例（功能、异常、边界、兼容性）
|
||||
- 评估测试工作量，规划测试排期
|
||||
- 定义测试准入/准出标准
|
||||
|
||||
### 2.2 功能测试
|
||||
- 执行冒烟测试（Smoke Test），验证提测版本可用性
|
||||
- 执行全量测试用例，记录测试结果
|
||||
- 发现 Bug 并提交到缺陷管理平台，清晰描述复现步骤
|
||||
- 回归测试：验证 Bug 修复，确保无新增问题
|
||||
- 探索性测试：发现用例未覆盖的缺陷
|
||||
|
||||
### 2.3 自动化测试
|
||||
- 搭建自动化测试框架（Selenium / Playwright / Appium）
|
||||
- 编写接口自动化测试脚本（pytest / JMeter / Postman）
|
||||
- 编写 UI 自动化测试脚本
|
||||
- 集成到 CI/CD 流水线，实现自动化回归
|
||||
- 维护自动化用例，保证脚本稳定性
|
||||
|
||||
### 2.4 性能测试
|
||||
- 制定性能测试方案，确定压测场景与指标
|
||||
- 使用 JMeter / Locust / k6 进行压力测试
|
||||
- 分析性能瓶颈（CPU/内存/IO/数据库慢查询）
|
||||
- 输出性能测试报告，给出优化建议
|
||||
- 生产环境容量评估与容量规划
|
||||
|
||||
### 2.5 安全测试
|
||||
- 执行安全扫描（OWASP Top 10）
|
||||
- SQL 注入、XSS、CSRF 等常见漏洞检测
|
||||
- API 接口权限验证、敏感数据泄露检查
|
||||
- 配合第三方安全公司进行渗透测试
|
||||
|
||||
### 2.6 质量度量
|
||||
- 统计缺陷密度、Bug 修复率、Bug 严重程度分布
|
||||
- 分析线上故障，推动故障复盘
|
||||
- 建立质量大盘，可视化质量趋势
|
||||
- 推动质量左移，提升提测质量
|
||||
|
||||
---
|
||||
|
||||
## 三、常用平台与工具
|
||||
|
||||
| 分类 | 工具 | 用途 |
|
||||
|------|------|------|
|
||||
| **缺陷管理** | Jira | Bug 跟踪与管理 |
|
||||
| | 禅道 | 国产缺陷管理 |
|
||||
| | 飞书项目 | Bug 跟踪 |
|
||||
| | Bugzilla / Mantis | 开源缺陷管理 |
|
||||
| **测试管理** | TestRail | 测试用例管理 |
|
||||
| | Xray（Jira 插件） | 测试管理+Jira集成 |
|
||||
| | TestLink | 开源测试管理 |
|
||||
| | PingCode | 测试用例与计划 |
|
||||
| **接口测试** | Postman / Apifox | 手动接口调试 |
|
||||
| | REST Assured | Java 接口自动化 |
|
||||
| | pytest + requests | Python 接口自动化 |
|
||||
| | JMeter | 接口压力测试 |
|
||||
| **UI 自动化** | Selenium | Web 自动化 |
|
||||
| | Playwright | 新一代 Web 自动化 |
|
||||
| | Cypress | 前端 E2E 测试 |
|
||||
| | Appium | 移动端自动化 |
|
||||
| | Airtest | 移动端/游戏自动化 |
|
||||
| **性能测试** | JMeter | 接口压力测试 |
|
||||
| | Locust | Python 性能测试 |
|
||||
| | k6 | 云原生性能测试 |
|
||||
| | Gatling | Scala 性能测试 |
|
||||
| | wrk / ab | 轻量 HTTP 压测 |
|
||||
| **安全测试** | OWASP ZAP | Web 安全扫描 |
|
||||
| | Burp Suite | 渗透测试 |
|
||||
| | SQLMap | SQL 注入检测 |
|
||||
| | Nmap | 端口扫描 |
|
||||
| **抓包与调试** | Charles / Fiddler | HTTP 抓包 |
|
||||
| | Proxyman | Mac 代理调试 |
|
||||
| | Whistle | 跨平台抓包 |
|
||||
| **数据库** | Navicat / DBeaver | 数据库管理 |
|
||||
| | RedisInsight | Redis 可视化 |
|
||||
| **CI/CD 集成** | Jenkins / GitLab CI / GitHub Actions | 自动化测试流水线 |
|
||||
| | Allure | 测试报告可视化 |
|
||||
|
||||
---
|
||||
|
||||
## 四、测试流程
|
||||
|
||||
```
|
||||
需求评审 → 测试计划 → 用例设计 → 用例评审 → 冒烟测试 → 功能测试 → 回归测试 → 验收测试 → 上线
|
||||
│ │ │ │ │ │ │ │ │
|
||||
▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
|
||||
提出可测 测试策略 用例库 团队评审 版本准入 执行用例 Bug验证 UAT参与 测试报告
|
||||
性建议 资源排期 TestRail 对齐标准 快速验证 Bug提交 全量回归 验收签字 质量评估
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 五、测试策略分层（测试金字塔）
|
||||
|
||||
```
|
||||
╱ 〰 ╲
|
||||
╱ E2E ╲ 少量端到端测试（全链路验证）
|
||||
╱──────────────╲
|
||||
╱ 集成测试 ╲ 中量集成测试（模块联调、API）
|
||||
╱──────────────────╲
|
||||
╱ 单元测试 ╲ 大量单元测试（函数/类级别）
|
||||
╱──────────────────────────╲
|
||||
成本 ⬆️ ｜ 速度 ⬇️
|
||||
```
|
||||
|
||||
- **单元测试**：占 70%，开发编写，CI 自动运行
|
||||
- **接口/集成测试**：占 20%，测试+开发共同维护
|
||||
- **UI/E2E 测试**：占 10%，覆盖核心业务主流程
|
||||
|
||||
---
|
||||
|
||||
## 六、能力模型
|
||||
|
||||
| 级别 | 能力要求 |
|
||||
|------|----------|
|
||||
| **初级** | 执行功能测试，编写测试用例，提交 Bug |
|
||||
| **中级** | 独立负责模块测试，编写接口自动化脚本，性能测试执行 |
|
||||
| **高级** | 搭建自动化框架，主导性能/安全测试，制定测试策略 |
|
||||
| **资深** | 全链路质量体系搭建，测试左移/右移，团队赋能 |
|
||||
|
||||
| 通用能力 | 要求 |
|
||||
|----------|------|
|
||||
| 测试方法论 | 黑盒/白盒/灰盒、等价类、边界值、场景法 |
|
||||
| 编程能力 | Python/Java 至少一种，能写自动化脚本 |
|
||||
| SQL | 复杂查询、数据验证、造数据 |
|
||||
| Linux | 查看日志、部署服务、排查问题 |
|
||||
| 网络协议 | HTTP/HTTPS、TCP/IP、抓包分析 |
|
||||
| 业务理解 | 深度理解业务场景，设计有效用例 |
|
||||
| 细心与耐心 | 不放过任何一个异常现象 |
|
||||
|
||||
---
|
||||
|
||||
## 七、产出物清单
|
||||
|
||||
| 产出物 | 交付节点 |
|
||||
|--------|----------|
|
||||
| 测试计划 | 需求评审后 |
|
||||
| 测试用例 | 编码阶段 |
|
||||
| 冒烟测试报告 | 提测后 |
|
||||
| Bug 报告 | 测试过程中 |
|
||||
| 功能测试报告 | 测试完成 |
|
||||
| 性能测试报告 | 性能测试后 |
|
||||
| 安全测试报告 | 安全测试后 |
|
||||
| 自动化测试脚本 | 持续维护 |
|
||||
| 质量月报 | 每月 |
|
||||
255
docs/Obsidian笔记体系/Projects/瑞来兹软件公司组织架构/组织架构.md
Normal file
255
docs/Obsidian笔记体系/Projects/瑞来兹软件公司组织架构/组织架构.md
Normal file
@@ -0,0 +1,255 @@
|
||||
# 瑞来兹软件公司组织架构
|
||||
|
||||
> 更新日期：2026-05-04
|
||||
|
||||
---
|
||||
|
||||
## 一、公司概况
|
||||
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 公司全称 | 瑞来兹软件技术有限公司 |
|
||||
| 英文名称 | Ruilaizi Software Technology Co., Ltd. |
|
||||
| 成立时间 | 2023-03-01 |
|
||||
| 主营业务 | 企业级SaaS平台研发、政企数字化解决方案、AI智能应用 |
|
||||
| 总部地址 | 杭州市余杭区未来科技城 |
|
||||
| 员工总数 | 86 人 |
|
||||
|
||||
---
|
||||
|
||||
## 二、组织架构总图
|
||||
|
||||
```
|
||||
股东会
|
||||
│
|
||||
董事会
|
||||
│
|
||||
总经理（CEO）
|
||||
│
|
||||
┌─────────────────┼─────────────────────┐
|
||||
│ │ │
|
||||
副总经理(CTO) 副总经理(COO) 副总经理(CMO)
|
||||
│ │ │
|
||||
┌────┼────┐ ┌────┼────┐ ┌────┼────┐
|
||||
│ │ │ │ │ │ │ │ │
|
||||
技 质 运 产 项 客 市 销 渠
|
||||
术 量 维 品 目 户 场 售 道
|
||||
部 部 部 部 管 成 部 部 部
|
||||
理 功
|
||||
部 部
|
||||
|
||||
┌─────────┼─────────┐
|
||||
│ │ │
|
||||
财务部 人事行政部 法务部
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 三、部门设置
|
||||
|
||||
### 3.1 总经办（3人）
|
||||
|
||||
| 职位 | 姓名 | 职责 |
|
||||
|------|------|------|
|
||||
| 总经理 / CEO | 陈瑞来 | 全面主持公司工作，制定战略方向 |
|
||||
| 总经理助理 | 林晓雨 | 协助总经理日常事务、会议安排 |
|
||||
| 战略顾问 | 张国栋 | 行业趋势研究、战略规划建议 |
|
||||
|
||||
### 3.2 技术部（32人）
|
||||
|
||||
**部门负责人：CTO 王浩然**
|
||||
|
||||
**3.2.1 研发一组 — 核心平台**
|
||||
| 职位 | 姓名 | 方向 |
|
||||
|------|------|------|
|
||||
| 技术总监（兼） | 王浩然 | 技术架构决策 |
|
||||
| 架构师 | 赵明远 | 微服务架构、分布式系统 |
|
||||
| 高级开发工程师 | 周子涵 | 后端（Go/Java） |
|
||||
| 高级开发工程师 | 吴思远 | 后端（Go） |
|
||||
| 开发工程师 | 郑小磊 | 后端（Java） |
|
||||
| 开发工程师 | 冯佳琪 | 后端（Python） |
|
||||
| 前端负责人 | 陈思成 | React/Vue 架构 |
|
||||
| 前端开发工程师 | 蒋雨桐 | React |
|
||||
| 前端开发工程师 | 沈梦琪 | Vue |
|
||||
|
||||
**3.2.2 研发二组 — 数据与AI**
|
||||
| 职位 | 姓名 | 方向 |
|
||||
|------|------|------|
|
||||
| AI技术负责人 | 黄志远 | NLP/CV 算法 |
|
||||
| 算法工程师 | 许晨曦 | 推荐系统 |
|
||||
| 算法工程师 | 孙浩然 | 大模型应用 |
|
||||
| 数据工程师 | 马晓东 | 数据仓库/ETL |
|
||||
| 数据工程师 | 朱晓峰 | 数据管道 |
|
||||
| 后端开发工程师 | 胡俊杰 | AI平台后端 |
|
||||
| 前端开发工程师 | 林雨欣 | AI产品前端 |
|
||||
|
||||
**3.2.3 移动端组**
|
||||
| 职位 | 姓名 | 方向 |
|
||||
|------|------|------|
|
||||
| 移动端负责人 | 何志强 | iOS/Android |
|
||||
| iOS开发工程师 | 高思琪 | Swift |
|
||||
| Android开发工程师 | 罗浩然 | Kotlin |
|
||||
| 跨端开发工程师 | 梁晓雯 | Flutter |
|
||||
|
||||
**3.2.4 质量部（QA）**
|
||||
| 职位 | 姓名 | 方向 |
|
||||
|------|------|------|
|
||||
| 测试负责人 | 刘思敏 | 测试策略、自动化 |
|
||||
| 高级测试工程师 | 杨帆 | 自动化测试 |
|
||||
| 测试工程师 | 宋佳怡 | 功能测试 |
|
||||
| 测试工程师 | 唐志远 | 性能测试 |
|
||||
| 测试工程师 | 董明月 | 安全测试 |
|
||||
|
||||
**3.2.5 运维部（DevOps）**
|
||||
| 职位 | 姓名 | 方向 |
|
||||
|------|------|------|
|
||||
| 运维负责人 | 谢鹏飞 | 基础设施架构 |
|
||||
| 运维工程师 | 韩志强 | K8s/CICD |
|
||||
| 运维工程师 | 钱晓宇 | 云平台管理 |
|
||||
| 运维工程师 | 崔佳明 | 监控告警 |
|
||||
|
||||
### 3.3 产品部（10人）
|
||||
|
||||
**部门负责人：产品总监 苏婉清**
|
||||
|
||||
| 职位 | 姓名 | 方向 |
|
||||
|------|------|------|
|
||||
| 产品总监 | 苏婉清 | 产品战略规划 |
|
||||
| 高级产品经理 | 魏志豪 | SaaS核心平台 |
|
||||
| 产品经理 | 蒋思琪 | AI产品线 |
|
||||
| 产品经理 | 沈浩宇 | 移动端产品 |
|
||||
| 产品经理 | 邓雨晴 | 数据产品 |
|
||||
| 产品助理 | 彭小军 | 需求整理 |
|
||||
| 产品助理 | 贾思雨 | 竞品分析 |
|
||||
| UX设计负责人 | 方悦然 | 交互与视觉 |
|
||||
| UI设计师 | 袁梦洁 | 视觉设计 |
|
||||
| UI设计师 | 田雨桐 | 设计系统 |
|
||||
|
||||
### 3.4 项目部（8人）
|
||||
|
||||
**部门负责人：COO 刘建国（兼）**
|
||||
|
||||
| 职位 | 姓名 | 方向 |
|
||||
|------|------|------|
|
||||
| 项目总监 | 丁志远 | 项目群管理 |
|
||||
| 项目经理（PMP） | 何其芳 | 政企项目交付 |
|
||||
| 项目经理 | 姚思远 | SaaS产品迭代 |
|
||||
| 项目经理 | 段晓明 | AI项目交付 |
|
||||
| 项目助理 | 龚雨菲 | 项目文档/OA |
|
||||
| 项目助理 | 赖志豪 | 资源协调 |
|
||||
| 客户成功经理 | 武思琪 | 大客户 |
|
||||
| 客户成功专员 | 贺梦瑶 | 中小客户 |
|
||||
|
||||
### 3.5 市场部（6人）
|
||||
|
||||
**部门负责人：CMO 徐雅婷**
|
||||
|
||||
| 职位 | 姓名 | 方向 |
|
||||
|------|------|------|
|
||||
| 市场总监 | 徐雅婷（兼） | 品牌战略 |
|
||||
| 品牌经理 | 余浩然 | 品牌传播 |
|
||||
| 内容运营 | 蔡雨晨 | 新媒体/内容营销 |
|
||||
| SEM/SEO专员 | 潘志远 | 搜索营销 |
|
||||
| 活动策划 | 戴思颖 | 展会/沙龙 |
|
||||
| 市场研究 | 谭晓峰 | 行业分析 |
|
||||
|
||||
### 3.6 销售部（12人）
|
||||
|
||||
**部门负责人：销售总监 程志豪**
|
||||
|
||||
| 职位 | 姓名 | 方向 |
|
||||
|------|------|------|
|
||||
| 销售总监 | 程志豪 | 销售策略/大客户 |
|
||||
| 大客户经理 | 范志明 | 政企/央企 |
|
||||
| 大客户经理 | 廖思源 | 金融行业 |
|
||||
| 销售经理 | 邹浩然 | 华东区域 |
|
||||
| 销售经理 | 曾雨晴 | 华南区域 |
|
||||
| 销售经理 | 邱晓东 | 华北区域 |
|
||||
| 销售经理 | 彭志远 | 西南区域 |
|
||||
| 销售代表 | 付晓雯 | 华东 |
|
||||
| 销售代表 | 崔浩然 | 华南 |
|
||||
| 销售代表 | 康雨欣 | 华北 |
|
||||
| 渠道经理 | 龙志豪 | 合作伙伴管理 |
|
||||
| 渠道专员 | 白思琪 | 渠道运营 |
|
||||
|
||||
### 3.7 财务部（4人）
|
||||
|
||||
| 职位 | 姓名 | 职责 |
|
||||
|------|------|------|
|
||||
| 财务总监 | 万思远 | 财务管理/融资 |
|
||||
| 会计 | 孔祥瑞 | 总账/税务 |
|
||||
| 出纳 | 毛晓琳 | 资金管理 |
|
||||
| 财务助理 | 华雨晨 | 报销审核 |
|
||||
|
||||
### 3.8 人事行政部（6人）
|
||||
|
||||
| 职位 | 姓名 | 职责 |
|
||||
|------|------|------|
|
||||
| HRD | 柳思颖 | 人力资源战略 |
|
||||
| 招聘经理 | 倪志远 | 人才招聘 |
|
||||
| HRBP | 汤思琪 | 业务伙伴/员工关系 |
|
||||
| 薪酬福利专员 | 滕晓明 | 薪酬个税 |
|
||||
| 行政经理 | 殷雨桐 | 行政事务 |
|
||||
| 前台/行政助理 | 卞晓雨 | 接待/快递/办公用品 |
|
||||
|
||||
### 3.9 法务部（1人）
|
||||
|
||||
| 职位 | 姓名 | 职责 |
|
||||
|------|------|------|
|
||||
| 法务顾问 | 齐国栋 | 合同审查/知识产权 |
|
||||
|
||||
---
|
||||
|
||||
## 四、管理层级
|
||||
|
||||
```
|
||||
Level 1: 总经理（CEO）
|
||||
Level 2: 副总经理（CTO / COO / CMO）、财务总监、HRD
|
||||
Level 3: 部门总监/技术总监/产品总监/市场总监/销售总监/项目总监
|
||||
Level 4: 团队负责人/架构师/高级经理
|
||||
Level 5: 高级工程师/产品经理/客户经理
|
||||
Level 6: 工程师/专员/助理
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 五、决策机制
|
||||
|
||||
| 事项 | 决策层级 |
|
||||
|------|----------|
|
||||
| 战略方向、投融资 | 总经理 + 董事会 |
|
||||
| 跨部门重大事项 | 总经办周会（CEO+CTO+COO+CMO） |
|
||||
| 部门级决策 | 部门负责人 |
|
||||
| 技术架构决策 | CTO + 技术架构委员会 |
|
||||
| 产品路线图 | 产品总监 + CTO + CEO |
|
||||
| 人员编制与预算 | 部门负责人 → HRD/财务总监 → 总经理 |
|
||||
|
||||
---
|
||||
|
||||
## 六、协作流程
|
||||
|
||||
```
|
||||
需求输入 → 产品部（PRD） → 技术部（方案设计）
|
||||
│
|
||||
▼
|
||||
质量部（测试） → 运维部（发布）
|
||||
│
|
||||
▼
|
||||
客户成功部（交付/培训/反馈）
|
||||
```
|
||||
|
||||
- **SaaS产品迭代**：双周 Sprint，敏捷开发
|
||||
- **政企项目交付**：瀑布+敏捷混合，按里程碑交付
|
||||
- **AI产品**：月度迭代，模型持续优化
|
||||
|
||||
---
|
||||
|
||||
## 七、联系信息
|
||||
|
||||
| 类型 | 信息 |
|
||||
|------|------|
|
||||
| 总机 | 0571-8888-6666 |
|
||||
| 商务合作 | bd@ruilaizi.com |
|
||||
| 技术支持 | support@ruilaizi.com |
|
||||
| 招聘邮箱 | hr@ruilaizi.com |
|
||||
| 公司官网 | www.ruilaizi.com |
|
||||
136
docs/Obsidian笔记体系/Projects/瑞来兹软件公司组织架构/花名册.md
Normal file
136
docs/Obsidian笔记体系/Projects/瑞来兹软件公司组织架构/花名册.md
Normal file
@@ -0,0 +1,136 @@
|
||||
# 瑞来兹软件公司花名册
|
||||
|
||||
> 更新日期：2026-05-04
|
||||
> 员工总数：80 人（不含外部顾问）
|
||||
|
||||
---
|
||||
|
||||
## 花名册总表
|
||||
|
||||
| 工号 | 姓名 | 性别 | 部门 | 职位 | 入职日期 | 转正日期 | 手机号 | 企业邮箱 | 紧急联系人 | 紧急电话 |
|
||||
|------|------|------|------|------|----------|----------|--------|----------|------------|----------|
|
||||
| RZ001 | 陈瑞来 | 男 | 总经办 | 总经理/CEO | 2023-03-01 | 2023-03-01 | 13800010001 | chenrl@ruilaizi.com | 陈母 | 13800010002 |
|
||||
| RZ002 | 王浩然 | 男 | 技术部 | CTO/技术总监 | 2023-03-15 | 2023-06-15 | 13800020001 | wanghr@ruilaizi.com | 王妻 | 13800020002 |
|
||||
| RZ003 | 刘建国 | 男 | 总经办 | COO（兼项目） | 2023-04-01 | 2023-07-01 | 13800030001 | liujg@ruilaizi.com | 刘妻 | 13800030002 |
|
||||
| RZ004 | 徐雅婷 | 女 | 市场部 | CMO/市场总监 | 2023-04-15 | 2023-07-15 | 13800040001 | xuyt@ruilaizi.com | 徐母 | 13800040002 |
|
||||
| RZ005 | 林晓雨 | 女 | 总经办 | 总经理助理 | 2023-05-01 | 2023-08-01 | 13800050001 | linxy@ruilaizi.com | 林父 | 13800050002 |
|
||||
| RZ006 | 苏婉清 | 女 | 产品部 | 产品总监 | 2023-05-15 | 2023-08-15 | 13800060001 | suwq@ruilaizi.com | 苏母 | 13800060002 |
|
||||
| RZ007 | 万思远 | 男 | 财务部 | 财务总监 | 2023-06-01 | 2023-09-01 | 13800070001 | wansy@ruilaizi.com | 万妻 | 13800070002 |
|
||||
| RZ008 | 柳思颖 | 女 | 人事行政部 | HRD | 2023-06-01 | 2023-09-01 | 13800080001 | liusy@ruilaizi.com | 柳父 | 13800080002 |
|
||||
| RZ009 | 赵明远 | 男 | 技术部 | 架构师 | 2023-06-15 | 2023-09-15 | 13800090001 | zhaomy@ruilaizi.com | 赵妻 | 13800090002 |
|
||||
| RZ010 | 周子涵 | 男 | 技术部 | 高级开发工程师 | 2023-07-01 | 2023-10-01 | 13800100001 | zhouzh@ruilaizi.com | 周母 | 13800100002 |
|
||||
| RZ011 | 陈思成 | 男 | 技术部 | 前端负责人 | 2023-07-15 | 2023-10-15 | 13800110001 | chensc@ruilaizi.com | 陈妻 | 13800110002 |
|
||||
| RZ012 | 刘思敏 | 女 | 技术部 | 测试负责人 | 2023-08-01 | 2023-11-01 | 13800120001 | liusm@ruilaizi.com | 刘母 | 13800120002 |
|
||||
| RZ013 | 谢鹏飞 | 男 | 技术部 | 运维负责人 | 2023-08-15 | 2023-11-15 | 13800130001 | xiepf@ruilaizi.com | 谢妻 | 13800130002 |
|
||||
| RZ014 | 程志豪 | 男 | 销售部 | 销售总监 | 2023-09-01 | 2023-12-01 | 13800140001 | chengzh@ruilaizi.com | 程妻 | 13800140002 |
|
||||
| RZ015 | 丁志远 | 男 | 项目部 | 项目总监 | 2023-09-15 | 2023-12-15 | 13800150001 | dingzy@ruilaizi.com | 丁妻 | 13800150002 |
|
||||
| RZ016 | 黄志远 | 男 | 技术部 | AI技术负责人 | 2023-10-01 | 2024-01-01 | 13800160001 | huangzy@ruilaizi.com | 黄母 | 13800160002 |
|
||||
| RZ017 | 何志强 | 男 | 技术部 | 移动端负责人 | 2023-10-15 | 2024-01-15 | 13800170001 | hezq@ruilaizi.com | 何妻 | 13800170002 |
|
||||
| RZ018 | 魏志豪 | 男 | 产品部 | 高级产品经理 | 2023-11-01 | 2024-02-01 | 13800180001 | weizh@ruilaizi.com | 魏母 | 13800180002 |
|
||||
| RZ019 | 范志明 | 男 | 销售部 | 大客户经理 | 2023-11-15 | 2024-02-15 | 13800190001 | fanzm@ruilaizi.com | 范妻 | 13800190002 |
|
||||
| RZ020 | 何其芳 | 女 | 项目部 | 项目经理(PMP) | 2024-01-02 | 2024-04-02 | 13800200001 | heqf@ruilaizi.com | 何母 | 13800200002 |
|
||||
| RZ021 | 吴思远 | 男 | 技术部 | 高级开发工程师 | 2024-01-15 | 2024-04-15 | 13800210001 | wusy@ruilaizi.com | 吴妻 | 13800210002 |
|
||||
| RZ022 | 郑小磊 | 男 | 技术部 | 开发工程师 | 2024-02-01 | 2024-05-01 | 13800220001 | zhengxl@ruilaizi.com | 郑母 | 13800220002 |
|
||||
| RZ023 | 冯佳琪 | 女 | 技术部 | 开发工程师 | 2024-02-15 | 2024-05-15 | 13800230001 | fengjq@ruilaizi.com | 冯父 | 13800230002 |
|
||||
| RZ024 | 蒋雨桐 | 女 | 技术部 | 前端开发工程师 | 2024-03-01 | 2024-06-01 | 13800240001 | jiangyt@ruilaizi.com | 蒋母 | 13800240002 |
|
||||
| RZ025 | 沈梦琪 | 女 | 技术部 | 前端开发工程师 | 2024-03-15 | 2024-06-15 | 13800250001 | shenmq@ruilaizi.com | 沈父 | 13800250002 |
|
||||
| RZ026 | 许晨曦 | 男 | 技术部 | 算法工程师 | 2024-04-01 | 2024-07-01 | 13800260001 | xucx@ruilaizi.com | 许妻 | 13800260002 |
|
||||
| RZ027 | 孙浩然 | 男 | 技术部 | 算法工程师 | 2024-04-15 | 2024-07-15 | 13800270001 | sunhr@ruilaizi.com | 孙母 | 13800270002 |
|
||||
| RZ028 | 马晓东 | 男 | 技术部 | 数据工程师 | 2024-05-01 | 2024-08-01 | 13800280001 | maxd@ruilaizi.com | 马妻 | 13800280002 |
|
||||
| RZ029 | 朱晓峰 | 男 | 技术部 | 数据工程师 | 2024-05-15 | 2024-08-15 | 13800290001 | zhuxf@ruilaizi.com | 朱妻 | 13800290002 |
|
||||
| RZ030 | 胡俊杰 | 男 | 技术部 | 后端开发工程师 | 2024-06-01 | 2024-09-01 | 13800300001 | hujj@ruilaizi.com | 胡母 | 13800300002 |
|
||||
| RZ031 | 林雨欣 | 女 | 技术部 | 前端开发工程师 | 2024-06-15 | 2024-09-15 | 13800310001 | linyx@ruilaizi.com | 林父 | 13800310002 |
|
||||
| RZ032 | 高思琪 | 女 | 技术部 | iOS开发工程师 | 2024-07-01 | 2024-10-01 | 13800320001 | gaosq@ruilaizi.com | 高母 | 13800320002 |
|
||||
| RZ033 | 罗浩然 | 男 | 技术部 | Android开发工程师 | 2024-07-15 | 2024-10-15 | 13800330001 | luohr@ruilaizi.com | 罗妻 | 13800330002 |
|
||||
| RZ034 | 梁晓雯 | 女 | 技术部 | 跨端开发工程师 | 2024-08-01 | 2024-11-01 | 13800340001 | liangxw@ruilaizi.com | 梁母 | 13800340002 |
|
||||
| RZ035 | 杨帆 | 男 | 技术部 | 高级测试工程师 | 2024-08-01 | 2024-11-01 | 13800350001 | yangf@ruilaizi.com | 杨妻 | 13800350002 |
|
||||
| RZ036 | 宋佳怡 | 女 | 技术部 | 测试工程师 | 2024-08-15 | 2024-11-15 | 13800360001 | songjy@ruilaizi.com | 宋母 | 13800360002 |
|
||||
| RZ037 | 唐志远 | 男 | 技术部 | 性能测试工程师 | 2024-09-01 | 2024-12-01 | 13800370001 | tangzy@ruilaizi.com | 唐妻 | 13800370002 |
|
||||
| RZ038 | 董明月 | 女 | 技术部 | 安全测试工程师 | 2024-09-15 | 2024-12-15 | 13800380001 | dongmy@ruilaizi.com | 董父 | 13800380002 |
|
||||
| RZ039 | 韩志强 | 男 | 技术部 | 运维工程师 | 2024-10-01 | 2025-01-01 | 13800390001 | hanzq@ruilaizi.com | 韩妻 | 13800390002 |
|
||||
| RZ040 | 钱晓宇 | 男 | 技术部 | 运维工程师 | 2024-10-15 | 2025-01-15 | 13800400001 | qianxy@ruilaizi.com | 钱妻 | 13800400002 |
|
||||
| RZ041 | 崔佳明 | 男 | 技术部 | 运维工程师 | 2024-11-01 | 2025-02-01 | 13800410001 | cuijm@ruilaizi.com | 崔母 | 13800410002 |
|
||||
| RZ042 | 蒋思琪 | 女 | 产品部 | 产品经理 | 2024-11-15 | 2025-02-15 | 13800420001 | jiangsq@ruilaizi.com | 蒋父 | 13800420002 |
|
||||
| RZ043 | 沈浩宇 | 男 | 产品部 | 产品经理 | 2025-01-02 | 2025-04-02 | 13800430001 | shenhy@ruilaizi.com | 沈妻 | 13800430002 |
|
||||
| RZ044 | 邓雨晴 | 女 | 产品部 | 产品经理 | 2025-01-15 | 2025-04-15 | 13800440001 | dengyq@ruilaizi.com | 邓母 | 13800440002 |
|
||||
| RZ045 | 彭小军 | 男 | 产品部 | 产品助理 | 2025-02-01 | 2025-05-01 | 13800450001 | pengxj@ruilaizi.com | 彭父 | 13800450002 |
|
||||
| RZ046 | 贾思雨 | 女 | 产品部 | 产品助理 | 2025-02-15 | 2025-05-15 | 13800460001 | jiasy@ruilaizi.com | 贾母 | 13800460002 |
|
||||
| RZ047 | 方悦然 | 女 | 产品部 | UX设计负责人 | 2025-03-01 | 2025-06-01 | 13800470001 | fangyr@ruilaizi.com | 方母 | 13800470002 |
|
||||
| RZ048 | 袁梦洁 | 女 | 产品部 | UI设计师 | 2025-03-15 | 2025-06-15 | 13800480001 | yuanmj@ruilaizi.com | 袁父 | 13800480002 |
|
||||
| RZ049 | 田雨桐 | 女 | 产品部 | UI设计师 | 2025-04-01 | 2025-07-01 | 13800490001 | tianyt@ruilaizi.com | 田母 | 13800490002 |
|
||||
| RZ050 | 姚思远 | 男 | 项目部 | 项目经理 | 2025-04-15 | 2025-07-15 | 13800500001 | yaosy@ruilaizi.com | 姚妻 | 13800500002 |
|
||||
| RZ051 | 段晓明 | 男 | 项目部 | 项目经理 | 2025-05-01 | 2025-08-01 | 13800510001 | duanxm@ruilaizi.com | 段妻 | 13800510002 |
|
||||
| RZ052 | 龚雨菲 | 女 | 项目部 | 项目助理 | 2025-05-15 | 2025-08-15 | 13800520001 | gongyf@ruilaizi.com | 龚母 | 13800520002 |
|
||||
| RZ053 | 赖志豪 | 男 | 项目部 | 项目助理 | 2025-06-01 | 2025-09-01 | 13800530001 | laizh@ruilaizi.com | 赖父 | 13800530002 |
|
||||
| RZ054 | 武思琪 | 女 | 项目部 | 客户成功经理 | 2025-06-15 | 2025-09-15 | 13800540001 | wusq@ruilaizi.com | 武母 | 13800540002 |
|
||||
| RZ055 | 贺梦瑶 | 女 | 项目部 | 客户成功专员 | 2025-07-01 | 2025-10-01 | 13800550001 | hemy@ruilaizi.com | 贺母 | 13800550002 |
|
||||
| RZ056 | 余浩然 | 男 | 市场部 | 品牌经理 | 2025-07-15 | 2025-10-15 | 13800560001 | yuhr@ruilaizi.com | 余妻 | 13800560002 |
|
||||
| RZ057 | 蔡雨晨 | 女 | 市场部 | 内容运营 | 2025-08-01 | 2025-11-01 | 13800570001 | caiyc@ruilaizi.com | 蔡母 | 13800570002 |
|
||||
| RZ058 | 潘志远 | 男 | 市场部 | SEM/SEO专员 | 2025-08-15 | 2025-11-15 | 13800580001 | panzy@ruilaizi.com | 潘妻 | 13800580002 |
|
||||
| RZ059 | 戴思颖 | 女 | 市场部 | 活动策划 | 2025-09-01 | 2025-12-01 | 13800590001 | daisy@ruilaizi.com | 戴母 | 13800590002 |
|
||||
| RZ060 | 谭晓峰 | 男 | 市场部 | 市场研究 | 2025-09-15 | 2025-12-15 | 13800600001 | tanxf@ruilaizi.com | 谭妻 | 13800600002 |
|
||||
| RZ061 | 廖思源 | 男 | 销售部 | 大客户经理 | 2025-10-01 | 2026-01-01 | 13800610001 | liaosy@ruilaizi.com | 廖妻 | 13800610002 |
|
||||
| RZ062 | 邹浩然 | 男 | 销售部 | 销售经理（华东） | 2025-10-15 | 2026-01-15 | 13800620001 | zouhr@ruilaizi.com | 邹妻 | 13800620002 |
|
||||
| RZ063 | 曾雨晴 | 女 | 销售部 | 销售经理（华南） | 2025-11-01 | 2026-02-01 | 13800630001 | zengyq@ruilaizi.com | 曾母 | 13800630002 |
|
||||
| RZ064 | 邱晓东 | 男 | 销售部 | 销售经理（华北） | 2025-11-15 | 2026-02-15 | 13800640001 | qiuxd@ruilaizi.com | 邱妻 | 13800640002 |
|
||||
| RZ065 | 彭志远 | 男 | 销售部 | 销售经理（西南） | 2025-12-01 | 2026-03-01 | 13800650001 | pengzy@ruilaizi.com | 彭妻 | 13800650002 |
|
||||
| RZ066 | 付晓雯 | 女 | 销售部 | 销售代表 | 2025-12-01 | 2026-03-01 | 13800660001 | fuxw@ruilaizi.com | 付母 | 13800660002 |
|
||||
| RZ067 | 崔浩然 | 男 | 销售部 | 销售代表 | 2025-12-15 | 2026-03-15 | 13800670001 | cuihr@ruilaizi.com | 崔妻 | 13800670002 |
|
||||
| RZ068 | 康雨欣 | 女 | 销售部 | 销售代表 | 2026-01-02 | 2026-04-02 | 13800680001 | kangyx@ruilaizi.com | 康母 | 13800680002 |
|
||||
| RZ069 | 龙志豪 | 男 | 销售部 | 渠道经理 | 2026-01-15 | 2026-04-15 | 13800690001 | longzh@ruilaizi.com | 龙妻 | 13800690002 |
|
||||
| RZ070 | 白思琪 | 女 | 销售部 | 渠道专员 | 2026-02-01 | 2026-05-01 | 13800700001 | baisq@ruilaizi.com | 白母 | 13800700002 |
|
||||
| RZ071 | 孔祥瑞 | 男 | 财务部 | 会计 | 2026-02-01 | 2026-05-01 | 13800710001 | kongxr@ruilaizi.com | 孔妻 | 13800710002 |
|
||||
| RZ072 | 毛晓琳 | 女 | 财务部 | 出纳 | 2026-02-15 | - | 13800720001 | maoxl@ruilaizi.com | 毛母 | 13800720002 |
|
||||
| RZ073 | 华雨晨 | 女 | 财务部 | 财务助理 | 2026-03-01 | - | 13800730001 | huayc@ruilaizi.com | 华父 | 13800730002 |
|
||||
| RZ074 | 倪志远 | 男 | 人事行政部 | 招聘经理 | 2026-03-01 | - | 13800740001 | nizy@ruilaizi.com | 倪妻 | 13800740002 |
|
||||
| RZ075 | 汤思琪 | 女 | 人事行政部 | HRBP | 2026-03-15 | - | 13800750001 | tangsq@ruilaizi.com | 汤母 | 13800750002 |
|
||||
| RZ076 | 滕晓明 | 男 | 人事行政部 | 薪酬福利专员 | 2026-04-01 | - | 13800760001 | tengxm@ruilaizi.com | 滕妻 | 13800760002 |
|
||||
| RZ077 | 殷雨桐 | 女 | 人事行政部 | 行政经理 | 2026-04-01 | - | 13800770001 | yinyt@ruilaizi.com | 殷母 | 13800770002 |
|
||||
| RZ078 | 卞晓雨 | 女 | 人事行政部 | 前台/行政助理 | 2026-04-15 | - | 13800780001 | bianxy@ruilaizi.com | 卞母 | 13800780002 |
|
||||
| RZ079 | 齐国栋 | 男 | 法务部 | 法务顾问 | 2026-04-15 | - | 13800790001 | qigd@ruilaizi.com | 齐妻 | 13800790002 |
|
||||
| RZ080 | 张国栋 | 男 | 总经办 | 战略顾问 | 2026-05-01 | - | 13800800001 | zhanggd@ruilaizi.com | 张妻 | 13800800002 |
|
||||
|
||||
---
|
||||
|
||||
## 统计概览
|
||||
|
||||
### 按部门
|
||||
|
||||
| 部门 | 人数 |
|
||||
|------|------|
|
||||
| 总经办 | 4 |
|
||||
| 技术部 | 33 |
|
||||
| 产品部 | 10 |
|
||||
| 项目部 | 8 |
|
||||
| 市场部 | 6 |
|
||||
| 销售部 | 12 |
|
||||
| 财务部 | 4 |
|
||||
| 人事行政部 | 6 |
|
||||
| 法务部 | 1 |
|
||||
| **合计** | **84** |
|
||||
|
||||
### 按性别
|
||||
|
||||
| 性别 | 人数 | 占比 |
|
||||
|------|------|------|
|
||||
| 男 | 46 | 54.8% |
|
||||
| 女 | 38 | 45.2% |
|
||||
|
||||
### 按职级
|
||||
|
||||
| 职级 | 人数 |
|
||||
|------|------|
|
||||
| 高管（L1-L2） | 8 |
|
||||
| 总监/负责人（L3） | 7 |
|
||||
| 团队负责人/架构师（L4） | 9 |
|
||||
| 高级岗（L5） | 16 |
|
||||
| 初中级岗（L6） | 44 |
|
||||
|
||||
### 按入职年份
|
||||
|
||||
| 年份 | 入职人数 | 累计 |
|
||||
|------|----------|------|
|
||||
| 2023 | 20 | 20 |
|
||||
| 2024 | 21 | 41 |
|
||||
| 2025 | 24 | 65 |
|
||||
| 2026 | 19 | 84 |
|
||||
117
docs/Obsidian笔记体系/Projects/瑞来兹软件公司组织架构/规划/规划角色文档.md
Normal file
117
docs/Obsidian笔记体系/Projects/瑞来兹软件公司组织架构/规划/规划角色文档.md
Normal file
@@ -0,0 +1,117 @@
|
||||
# 规划
|
||||
|
||||
> 所属公司：瑞来兹软件技术有限公司
|
||||
> 更新日期：2026-05-04
|
||||
|
||||
---
|
||||
|
||||
## 一、角色定义
|
||||
|
||||
规划岗位（含项目规划师、敏捷教练、技术规划等角色）负责项目的整体规划、资源调度和过程管控，确保项目按时、按质、按预算交付。
|
||||
|
||||
---
|
||||
|
||||
## 二、主要职责
|
||||
|
||||
### 2.1 项目规划
|
||||
- 制定项目章程（Project Charter），明确项目范围、目标、干系人
|
||||
- 编制 WBS（工作分解结构），拆解可执行的任务单元
|
||||
- 制定项目排期（甘特图），确定关键路径与里程碑
|
||||
- 评估项目风险，制定风险应对预案
|
||||
- 编制项目预算，跟踪成本与投入产出比
|
||||
|
||||
### 2.2 资源管理
|
||||
- 协调跨部门资源（研发、测试、设计、运维）
|
||||
- 制定人力投入计划，避免资源冲突
|
||||
- 管理外部供应商与外包团队
|
||||
- 项目物料与软硬件资源的采购跟进
|
||||
|
||||
### 2.3 进度管控
|
||||
- 主持项目例会（周会/日站会），跟踪任务进度
|
||||
- 使用燃尽图（Burndown Chart）监控 Sprint 健康度
|
||||
- 识别并解决阻塞项（Blocker），及时升级风险
|
||||
- 变更管理：评估变更影响，走 CR（Change Request）流程
|
||||
|
||||
### 2.4 质量与交付
|
||||
- 定义 DoD（Definition of Done），确保交付标准
|
||||
- 组织阶段评审（需求评审、设计评审、代码评审）
|
||||
- 管理 UAT 测试与验收交付
|
||||
- 项目结项：归档文档、复盘总结（Retrospective）
|
||||
|
||||
### 2.5 敏捷实践
|
||||
- 担任 Scrum Master，推动敏捷转型
|
||||
- 引导 Sprint Planning、Daily Standup、Sprint Review、Retro
|
||||
- 度量团队敏捷成熟度，持续优化流程
|
||||
- 培训团队敏捷/精益方法论
|
||||
|
||||
---
|
||||
|
||||
## 三、常用平台与工具
|
||||
|
||||
| 分类 | 工具 | 用途 |
|
||||
|------|------|------|
|
||||
| **项目管理** | Jira | Sprint 管理、任务跟踪、报表 |
|
||||
| | Microsoft Project | 专业项目排期、甘特图 |
|
||||
| | Asana | 轻量团队任务管理 |
|
||||
| | Monday.com | 可视化项目管理 |
|
||||
| | 禅道 | 国产全流程项目管理 |
|
||||
| | PingCode | 研发项目管理 |
|
||||
| | 飞书项目 | 飞书生态项目管理 |
|
||||
| | Teambition | 钉钉生态项目管理 |
|
||||
| | Worktile | 国产协作与项目管理 |
|
||||
| | OmniPlan | Mac 端专业甘特图 |
|
||||
| **文档与知识库** | Confluence | 项目文档 Wiki |
|
||||
| | Notion | 项目知识库 |
|
||||
| | 语雀 | 团队知识沉淀 |
|
||||
| **进度可视化** | 甘特图（Excel/Project） | 里程碑计划 |
|
||||
| | 燃尽图（Burndown） | Sprint 进度跟踪 |
|
||||
| | Miro / MURAL | 线上白板、Retro 回顾 |
|
||||
| **沟通协作** | 飞书 / 钉钉 / 企业微信 | 日常沟通 |
|
||||
| | Slack | 国际团队 |
|
||||
| | Zoom / 腾讯会议 | 远程会议 |
|
||||
| **文档处理** | Office 365 / WPS | 文档、表格、演示 |
|
||||
| | Google Workspace | 在线协作 |
|
||||
| **时间管理** | Toggl / Clockify | 工时记录 |
|
||||
| | RescueTime | 时间分析 |
|
||||
|
||||
---
|
||||
|
||||
## 四、关键流程
|
||||
|
||||
```
|
||||
项目立项 → 需求评审 → 方案设计 → Sprint规划 → 开发实施 → 测试验证 → UAT → 上线发布 → 结项复盘
|
||||
│ │ │ │ │ │ │ │ │
|
||||
▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
|
||||
立项书 PRD评审 技术方案 Sprint 每日站会 Bug跟踪 验收报告 发布清单 复盘报告
|
||||
评审 Backlog
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 五、能力模型
|
||||
|
||||
| 能力 | 要求 |
|
||||
|------|------|
|
||||
| 项目管理 | PMP/PRINCE2/ACP 方法论、敏捷/瀑布混合 |
|
||||
| 风险管理 | 风险识别、概率评估、应对策略 |
|
||||
| 沟通协调 | 干系人管理、冲突解决、向上汇报 |
|
||||
| 时间管理 | 多项目并行管理、关键路径分析 |
|
||||
| 工具使用 | Jira/Project/甘特图等专业工具 |
|
||||
| 业务理解 | 快速理解行业背景与业务逻辑 |
|
||||
| 数据分析 | 项目度量指标、报表输出 |
|
||||
|
||||
---
|
||||
|
||||
## 六、产出物清单
|
||||
|
||||
| 产出物 | 交付节点 |
|
||||
|--------|----------|
|
||||
| 项目章程 | 立项阶段 |
|
||||
| WBS 工作分解 | 规划阶段 |
|
||||
| 项目排期（甘特图） | 规划阶段 |
|
||||
| 风险管理计划 | 规划阶段 |
|
||||
| 项目周报 | 每周 |
|
||||
| Sprint 燃尽图 | 每个 Sprint |
|
||||
| 阶段评审报告 | 里程碑节点 |
|
||||
| 变更申请单（CR） | 需求变更时 |
|
||||
| 项目复盘报告 | 结项 |
|
||||
1
docs/Obsidian笔记体系/Projects/腾讯云服务器/腾讯云服务器.md
Normal file
1
docs/Obsidian笔记体系/Projects/腾讯云服务器/腾讯云服务器.md
Normal file
@@ -0,0 +1 @@
|
||||
腾讯云root密码：{+2@#$[:Edf,!n&$19K
|
||||
Reference in New Issue
Block a user