Evilom
fe5505343e
- 通过悟空(dws CLI)拉取dc战略问题研究院+创新组两个群的消息(377条) - 提取190个飞书链接、18个文件附件 - 下载HTML/MD/XLSX等报告文件到output/downloaded-files/ - 构建知识图谱(JSON+HTML可视化) - 生成Obsidian知识库(28个页面,7大主题) - 生成花园世界全量汇总报告 - 所有脚本路径改为相对路径,便于迁移
356 lines
15 KiB
Markdown
356 lines
15 KiB
Markdown
# 我的花园世界 分析汇总报告
|
||
|
||
**生成时间**: 2026-06-02 11:58
|
||
**相关文档数**: 6 篇
|
||
**分析人员**: 黄静雯 (dc战略问题研究院)
|
||
|
||
---
|
||
|
||
## 2026-05-15 09:02:29
|
||
|
||
**链接**: https://dianchukeji.feishu.cn/docx/SOaBdskVhoSXo0x6gvbcLnKHntb
|
||
|
||
```n《三国：谋定天下》、《三国：天下归心》、《三国：冰河时代》、《我的花园世界》体验
|
||
2.
|
||
面试
|
||
3.
|
||
研究组AI研究工作流与产品认知资产库搭建推进
|
||
4.
|
||
创新组全栈 AI 开发方向思考及工作流搭建
|
||
二、研究组AI研究工作流与产品认知资产库搭建推进
|
||
原定开发计划包括：
|
||
1.
|
||
三谋三张 draft 卡正式入库 review（已完成）
|
||
2.
|
||
固化 MECH / REPORT / ORG 同源拆分规则（未开始）
|
||
3.
|
||
中规模增量同步验证（未开始）
|
||
4.
|
||
分类候选产物可读化（未开始）
|
||
5.
|
||
target 写回知识库的触发条件梳理（未开始）
|
||
（一）今日迭代内容
|
||
1.
|
||
完成《三国：谋定天下》演武大会三张知识卡正式入库
|
||
对三张卡进行了正式入库前 review，并完成正式入库状态切换
|
||
在 review 三张卡的过程中，进一步明确了同一研究资料拆分为多类知识卡时的边界：
|
||
MECH 卡
|
||
：回答“机制如何成立”
|
||
重点沉淀规则结构、机制模型、设计逻辑和可迁移机制
|
||
REPORT 卡
|
||
：回答“机制为什么对产品有价值”
|
||
重点沉淀产品观察、用户价值、产品价值和商业化待验证方向
|
||
ORG 卡
|
||
：回答“机制如何影响玩家组织与参与结构”
|
||
重点沉淀组织压力、参与门槛、协作方式和组织生态影响
|
||
这次三谋演武大会案例是第一次完整跑通“同一研究对象拆分为 MECH / REPORT / ORG 三类知识资产”的验证案例。过程中暴露出一个关键问题：
|
||
不同卡片之间天然会存在交叉，如果没有清晰的拆分规则，很容易变成重复总结
|
||
。因此补充了工作流规则，明确三类卡片不是并列复述，而是
|
||
从不同知识资产视角拆分同一机制对象
|
||
后续会继续扩大资料规模，单篇材料里会同时包含：
|
||
机制规则
|
||
产品判断
|
||
用户反馈
|
||
组织生态
|
||
商业化推演
|
||
竞品对比
|
||
后续行动建议
|
||
如果不拆分，就会变成一篇越来越长的综合报告，后续很难复用。MECH / REPORT / ORG 的价值在于把研究内容拆成更稳定的知识单元：
|
||
机制
|
||
产品观察
|
||
组织生态归
|
||
商业化推演保留证据边界
|
||
C 类推演判断非客观事实
|
||
```n
|
||
---
|
||
|
||
## 2026-05-14 09:29:52
|
||
|
||
**链接**: https://dianchukeji.feishu.cn/docx/GuJRdtHTKoQ8QaxVbGecxhuDn5Q
|
||
|
||
```n《我的花园世界》体验
|
||
3.
|
||
AI研究工作流与产品认知资产库搭建推进
|
||
二、AI研究工作流与产品认知资产库搭建推进
|
||
原定开发计划包括：
|
||
1.
|
||
固化 Feishu MCP Source User SOP
|
||
梳理 source user 使用说明
|
||
固化 auth / smoke / sync / classify 标准命令
|
||
明确常见错误与处理方式
|
||
说明 data / dist / token / env 目录处理规则
|
||
从干净 git 状态复跑一次端到端流程
|
||
将 SOP 写入 README 或 workflow 文档
|
||
补充 HTML 版本，提高可读性
|
||
生成 share 页面，便于团队阅读
|
||
2.
|
||
《三国：谋定天下》补齐 P0 完整闭环
|
||
基于三谋已同步资料生成资产候选清单
|
||
人工 review，确认哪些候选值得沉淀
|
||
生成 MECH / REPORT / ORG 卡片
|
||
输出 HTML 页面
|
||
与《我的花园世界》形成对比案例
|
||
检查第二产品 SOP 是否真正可复用
|
||
（一）今日迭代内容
|
||
完成“半自动知识资产生产链路”的 P0 本地验证，
|
||
支持把日常研究资料转化为结构化知识资产
|
||
；但正式入库、多人 review、target 知识库写回和全自动闭环仍需要继续推进
|
||
过去大量研究结论沉淀在分散的飞书文档中，难以复用；现在开始把资料同步、候选识别、机制卡片、HTML展示、索引发现这一整套流程固化下来，
|
||
让战略研究部的研究结果逐步变成部门及组织内部长期可复用的知识资产
|
||
实际上，由于Feishu MCP目前设计使用的是user_access_token（可读取用户有权限的文档），理论上只要我的账号有访问权限，所有的云文档（doc/docx）均可被处理转化为知识资产
|
||
1.
|
||
固化 Feishu MCP Source User SOP
|
||
Feishu MCP Source User SOP 已完成 P0 基础固化，
|
||
具备支撑第二产品验证和后续知识资产生产的能力
|
||
，但正式知识库写回与多人协作流程仍属于 v0.4+ 规划。基于前一日已跑通的 Feishu MCP Source User 链路，将其进一步整理为
|
||
可阅读
|
||
可复用
|
||
可交接
|
||
的 SOP 文档，并同步生成了 HTML / share 页面。主要完成内容包括：
|
||
固化 Feishu MCP Source User 的使用边界
|
||
明确组织1 / 组织2的关系和定位
|
||
补充 source user OAuth、smoke、sync、classify 的标准命令说明
|
||
区分终端命令与 Claude Code MCP 工具调用
|
||
明确 data / dist / token / env 等目录处理规则
|
||
补充常见错误与处理方式
|
||
生成 Feishu MCP Source User SOP 的 HTML 页面与 share 版本
|
||
将 SOP 链接与入口同步到 README / 工作流总览中
|
||
点击查看：
|
||
Feishu MCP Source User SOP — 战略研究部
|
||
61%
|
||
39%
|
||
```n
|
||
---
|
||
|
||
## 2026-05-13 02:58:37
|
||
|
||
**链接**: https://dianchukeji.feishu.cn/docx/ExYndBzwSoEobXxqgiicDkionnh
|
||
|
||
```n《我的花园世界》体验
|
||
3.
|
||
AI研究工作流与产品认知资产库搭建推进
|
||
二、AI研究工作流与产品认知资产库搭建推进
|
||
（一）今日迭代内容
|
||
原定开发计划包括：
|
||
1.
|
||
配置 source App 权限
|
||
2.
|
||
跑 live smoke test（权限配置完成后）
|
||
3.
|
||
开发 v0.3 日报自动分类与资产候选
|
||
4.
|
||
用《三国：谋定天下》验证 SOP 稳定性
|
||
AI 研究工作流
|
||
跑通了从飞书原始资料读取到本地结构化、规则分类、资产候选 review 的基础闭环
|
||
相比此前依赖人工导出、人工整理、人工复制资料，当前已经形成了更可复用的自动化底座，为后续将历史日报、会议纪要、专题研究沉淀为可复用知识资产提供了基础
|
||
飞书原始资料
|
||
user OAuth 读取
|
||
本地 Markdown 镜像
|
||
正文结构化
|
||
规则分类
|
||
资产候选
|
||
人工 review
|
||
1.
|
||
Feishu MCP Server 今日实际迭代内容
|
||
1.
|
||
完成 source App 权限配置，并明确当前主路径为 source user OAuth
|
||
source user OAuth：当前读取组织1原始资料的主路径
|
||
tenant token：路径保留，但不是当前主路径
|
||
说明：
|
||
原本预期是通过 source App 的 tenant token 读取组织1资料，但实际验证后发现，组织1中的日报和历史资料主要是共享给我个人账号的，source App 的 tenant_access_token 并不会自动继承我个人账号对这些文档的阅读权限
|
||
本次完成了 source App 权限、OAuth redirect_uri、user token 缓存、安全忽略等相关配置，并跑通了 source user 授权链路
|
||
2.
|
||
跑通 live smoke test，并完成真实小样本同步
|
||
权限配置完成后，继续进行了 live smoke test。
|
||
完成了从飞书搜索、读取、同步到本地的真实链路
|
||
。已验证能力包括：
|
||
searchDocs：可搜索真实飞书日报/报告
|
||
getDocContent：可读取 docx 正文
|
||
syncDocs：可将文档同步为本地 Markdown
|
||
manifest：可记录同步文档列表与路径信息
|
||
data 产物：未进入 Git，符合安全边界
|
||
3.
|
||
修复日期解析问题，避免 1970-01-01 污染
|
||
在同步过程中发现，部分文件由于飞书返回的
|
||
updated_time
|
||
不可靠，会导致文件名前缀出现：1970-01-01_...，
|
||
影响后续按日期索引、日报排序、增量同步和周/月汇总
|
||
```n
|
||
---
|
||
|
||
## 2026-05-12 00:57:55
|
||
|
||
**链接**: https://dianchukeji.feishu.cn/docx/N6J5duouUo2ip7xlyBdcJbkYnxg
|
||
|
||
```n《我的花园世界》体验
|
||
3.
|
||
AI研究工作流与产品认知资产库搭建推进
|
||
二、AI研究工作流与产品认知资产库搭建推进
|
||
（一）今日迭代内容
|
||
推进解决
|
||
历史报告依赖人工导出
|
||
的问题，开始推进
|
||
Feishu MCP Server（飞书知识检索与结构化读取服务）
|
||
让 Claude Code 通过 MCP 工具调用飞书开放平台 API，实现搜索、读取、同步、结构化索引
|
||
1.
|
||
Feishu MCP Server v0.1：MCP 框架完成
|
||
MCP Server 基础目录结构
|
||
TypeScript 工程配置
|
||
6 个 MCP mock tools
|
||
feishu_search_docs ---搜索飞书云文档
|
||
feishu_search_wiki---搜索飞书知识库
|
||
feishu_get_doc_content---读取文档正文
|
||
feishu_sync_docs---批量同步为本地 Markdown
|
||
feishu_classify_synced_docs--识别日报 / 报告 / 会议纪要类型
|
||
feishu_build_research_indexes--生成项目 / 日期 / 资产索引
|
||
README / 权限说明 / 安全说明 / v0.2 API 接入计划
|
||
mock 模式启动验证
|
||
2.
|
||
Feishu MCP Server v0.2：真实飞书 API 路径开发完成
|
||
tenant_access_token 获取与缓存逻辑
|
||
Feishu OpenAPI request 封装
|
||
feishu_search_docs live 分支
|
||
feishu_get_doc_content live 分支
|
||
feishu_sync_docs live 分支
|
||
本地 Markdown 写入与 manifest 输出路径
|
||
mock fallback
|
||
缺少凭证时自动 mock
|
||
错误日志脱敏
|
||
README / .env.example / config.example.yaml 更新
|
||
3.
|
||
双组织架构调整：组织1读取原始报告，组织2沉淀知识库
|
||
source tenant
|
||
（组织1：厦门点触科技股份有限公司）：
|
||
只读原始报告
|
||
当前原始日报、专项报告、会议纪要等存放组织
|
||
我非管理员，免费版云盘容量较小
|
||
target tenant
|
||
（组织2：厦门点触科技股份有限公司广州分公司）：
|
||
长期知识库沉淀目标，未来写入
|
||
此前已由我创建并做了企业认证
|
||
商业版容量较大，后续用于沉淀稳定知识卡片、SOP、研究结论
|
||
4.
|
||
战略研究部 AI 工作流开发进度总览更新
|
||
点击查看：
|
||
战略研究部 AI 研究工作流总览
|
||
```n
|
||
---
|
||
|
||
## 2026-05-10 03:33:49
|
||
|
||
**链接**: https://dianchukeji.feishu.cn/docx/Me8ed6Rfso05rDxG0yBcDfU5n17
|
||
|
||
```n《我的花园世界》体验
|
||
3.
|
||
AI研究工作流与产品认知资产库搭建推进
|
||
二、AI研究工作流与产品认知资产库搭建推进
|
||
（一）当前版本内容
|
||
当前版本已经具备几类基础能力：
|
||
1.
|
||
本地 Claude Code 研究生产层已形成基本结构
|
||
本地工作区已经具备 workflows、templates、prompts、knowledge、data、reports、archive 等目录结构，并通过 Git 管理版本
|
||
P0 工作流底座中已经包含信息收集、事实核验、竞品分析、机制拆解、社区反馈分析、产品反哺、知识卡片生成等基础 SOP
|
||
2.
|
||
知识卡片体系已从机制卡片扩展到多类型卡片
|
||
当前已经形成机制卡片、AI 机会卡片、ORG 组织方法论卡片等多类知识资产
|
||
3.
|
||
历史报告本地镜像流程已跑通
|
||
飞书历史资料已经可以通过“人工复制/导出 → 本地 Markdown 镜像 → Claude Code 分析”的方式进入本地研究生产流程
|
||
4.
|
||
HTML 展示与分享链路已初步可用
|
||
除单个机制卡片可生成 HTML 进行展示与分享外，还可统一站点入口，将总览页和多个相关机制卡片整合在一起，并可通过 Netlify Drop 等静态托管方式生成可分享链接
|
||
点击查看：
|
||
战略研究部 AI 研究工作流总览
|
||
10%
|
||
15%
|
||
16%
|
||
15%
|
||
12%
|
||
13%
|
||
18%
|
||
（二）主要迭代内容
|
||
AI研究工作流已经从“单点机制拆解测试”推进到“多份历史报告批处理与可视化分享流程”
|
||
，当前能力变化主要体现在：
|
||
1.
|
||
从单篇机制拆解，升级为多份历史报告处理
|
||
此前主要验证的是单个机制案例能否拆解成报告和机制卡片。本轮则验证了多份历史报告能否通过 index.md 管理输入，再统一生成资产清单和卡片化建议
|
||
2.
|
||
从 Markdown 卡片，升级为 Markdown + HTML 展示
|
||
Markdown 仍然作为知识源和长期沉淀格式，HTML 则作为展示层和分享层。这个分工比较清晰：知识沉淀不依赖 HTML，但对外分享和内部快速阅读可以通过 HTML 页面提升效率
|
||
3.
|
||
从手动零散操作，开始固化为 SOP
|
||
《我的花园世界》这一轮已经形成较完整的可复用链路，后续可以用第二个项目继续验证该 SOP 是否稳定
|
||
本轮以《我的花园世界》为测试对象，完成了
|
||
从历史报告到机制资产的完整处理流程
|
||
飞书历史报告本地镜像
|
||
index.md 多文件索引
|
||
资产清单与卡片化建议
|
||
人工确认生成哪些卡片
|
||
机制卡片
|
||
HTML 单卡页
|
||
HTML 总览页
|
||
HTML 索引站点
|
||
可部署分享包
|
||
```n
|
||
---
|
||
|
||
## 2026-05-09 03:31:23
|
||
|
||
**链接**: https://dianchukeji.feishu.cn/docx/UNLydXXQNoGXUCxejlXczf5CnVh
|
||
|
||
```n《我的花园世界》新号体验（微信小游戏）
|
||
二、《我的花园世界》新号首日体验
|
||
此前个人对《我的花园世界》的体验较浅，主要针对GVG相关的公会系统及公会竞赛进行了机制分析
|
||
2026年3月27日工作日报-黄静雯
|
||
，今日起补充完整体验
|
||
（一）首日体验进度
|
||
（二）首日体验观察点
|
||
1.
|
||
新手教学期设计比同类产品更长、更密集
|
||
主线任务中包含大量
|
||
非累计式任务
|
||
，截止主线任务84仍存在大量核心玩法循环相关非累计式任务，
|
||
适配《我的花园世界》的核心用户（25-45岁女性、宝妈、小游戏轻度用户）
|
||
这类大量非累计式任务虽然会制造重复感和资源消耗压力，但在新手期承担了很强的
|
||
行为教育功能
|
||
理解基础循环
|
||
：不能只把种花、收花、订单当成点击操作，而要理解它们之间的资源关系
|
||
从“完成任务”转向“管理任务”
|
||
看到任务 → 判断资源是否够 → 判断订单是否该交 → 判断花是否该留 → 判断是否需要去好友家补资源
|
||
。让玩家逐渐意识到：
|
||
订单不是有就交，资源不是有就用，成熟花也不是有就收
|
||
培养库存管理意识
|
||
资源的价值不是固定的
|
||
，取决于当前任务链及订单需求
|
||
核心玩法循环的关键资源约束：
|
||
水滴：播种后需浇一次水，水滴每2分钟恢复1点，上限65点（平均每2小时需上线游戏）
|
||
鲜花培育材料：药剂+肥料+土壤+能量瓶，材料商店随机刷新，急需时可用元宝购买
|
||
花坊币：极稀缺，仅通过订单获取（1单1-3个），用于解锁新花种
|
||
为公会系统及公会竞赛做前置训练
|
||
：前期大量非累计任务，不只是为了主线教学，更是在为后续公会竞赛的任务制、贡献制、资源调度做认知铺垫
|
||
种植节奏
|
||
：什么花何时种、何时收、何时留
|
||
订单消耗
|
||
：订单不是无脑交，要考虑后续任务
|
||
资源缺口
|
||
：水、金币、花、材料都会卡节奏
|
||
好友补位
|
||
：好友不是社交装饰，而是资源来源
|
||
任务驱动
|
||
：后续公会竞赛也是任务驱动型玩法
|
||
强化理解为什么公会任务不能乱接、为什么任务资源要协调、为什么会长会管理任务归属
|
||
2.
|
||
社交引入及压力梯度
|
||
完成主线任务29可解锁好友系统，每日任务里有摘取好友40朵花的要求引导玩家加好友。公会系统需要完成主线任务115才解锁（预估时间2-3天）
|
||
防止竞赛难民
|
||
：公会竞赛任务需要特定鲜花（如鸳鸯茉莉、赤焰火焰兰等），前期玩家花种匮乏，接取任务后无法完成，既浪费公会任务刷新次数，又导致个人竞赛积分归零
|
||
确保资产沉淀
|
||
：115关时玩家通常已解锁花坊系统、拥有10+鲜花种类、理解培育-种植-订单循环，此时进入公会才能立即产生正向贡献
|
||
匹配小游戏留存曲线
|
||
：微信小游戏用户前7日流失率极高，将高粘性玩法（公会GVG）后置到第2-3天，可以筛选出高意向核心用户，
|
||
降低公会管理成本
|
||
```n
|
||
---
|
||
|
||
|