commit fe5505343e1f8575198406da31b57bc1e39f393d Author: Evilom <33251918+Evilom@users.noreply.github.com> Date: Tue Jun 2 20:24:25 2026 +0800 feat: 钉钉群聊飞书文档收集与知识图谱系统初始提交 - 通过悟空(dws CLI)拉取dc战略问题研究院+创新组两个群的消息(377条) - 提取190个飞书链接、18个文件附件 - 下载HTML/MD/XLSX等报告文件到output/downloaded-files/ - 构建知识图谱(JSON+HTML可视化) - 生成Obsidian知识库(28个页面,7大主题) - 生成花园世界全量汇总报告 - 所有脚本路径改为相对路径,便于迁移 diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..c384320 --- /dev/null +++ b/.gitignore @@ -0,0 +1,68 @@ +# Dependencies +node_modules/ + +# Large media files (videos 186MB+, PPTs 307MB+) +videos/ +dc_files/ +工作流总结-王雨默.html + +# Temp/intermediate files +.claude/ +dingtalk-workspace-temp/ +full_content_progress.json +read_progress.json +browser_extracted_docs.json +feishu_content.json +feishu_docs_content.json +feishu_docs_sample.json +feishu_links_*.json +feishu_summary_*.md +access_test.csv +docs_index.csv +batch_fetch.js +package.json +package-lock.json +test_docs.ps1 +extract_title.ps1 +fetch_accessible_docs.ps1 +generate_summary.ps1 + +# Intermediate Python scripts (not needed for reproduction) +generate_full_content_report.py +generate_full_report.py +generate_report.py +generate_report_v2.py +generate_report_simple.py +read_all_docs.py +read_batch.py +read_feishu_docs.py + +# Intermediate reports +analysis_report.md +research_analysis.md +academic_research_details.md +technical_solutions.md +summary.md +full_content_report.md + +# Raw data dumps (regenerable) +data/raw-messages/ + +# Duplicate of obsidian_vault (kept in output/) +obsidian_vault/ + +# Duplicate of dc_html_md (kept in output/) +dc_html_md/ + +# Python cache +__pycache__/ +*.pyc + +# Env files +.env +.env.* + +# OS files +Thumbs.db +Desktop.ini +.DS_Store \ No newline at end of file diff --git a/README.md b/README.md new file mode 100644 index 0000000..5a4a113 --- /dev/null +++ b/README.md @@ -0,0 +1,111 @@ +# 钉钉群聊飞书文档收集与知识图谱系统 + +从钉钉群聊「dc战略问题研究院」和「创新组」中自动收集飞书链接、文件附件,读取内容并整理为结构化知识图谱和 Obsidian 知识库。 + +## 项目背景 + +公司战略研究团队每天在钉钉群中分享飞书文档(研究报告、竞品分析、日报等),本项目自动化完成: + +1. **采集**:通过悟空(dws CLI)拉取群聊消息,提取飞书链接和文件附件 +2. **下载**:下载 HTML/MD/XLSX 等文件附件 +3. **解析**:读取文档内容,提取关键信息 +4. **结构化**:构建知识图谱(JSON)和 Obsidian 知识库 +5. **汇总**:生成主题汇总报告 + +## 目录结构 + +``` +├── output/ ← 核心产出 +│ ├── reports/ ← 汇总报告 +│ │ ├── 花园世界全量汇总.md ← 《我的花园世界》全量研究汇总 +│ │ └── ... +│ ├── knowledge-graph/ ← 知识图谱 +│ │ ├── knowledge_graph.json ← 结构化数据(28人/190文档/7主题) +│ │ ├── knowledge_graph.html ← 可视化网页 +│ │ └── knowledge_graph_mermaid.md +│ ├── obsidian-vault/ ← Obsidian 知识库(可直接打开) +│ │ ├── 00-MOC/ ← 主索引入口 +│ │ ├── 01-产品研究/ ← 10个产品分析页面 +│ │ ├── 02-方法论/ ← 5个方法论页面 +│ │ ├── 03-项目落地/ ← 3个落地方案 +│ │ ├── 04-人物/ ← 3个人物页面 +│ │ ├── 05-行业趋势/ ← 2个趋势页面 +│ │ └── 06-数据与索引/ ← 3个数据页面 +│ └── downloaded-files/ ← 从钉盘下载的原始文件 +│ ├── html-md/ ← HTML/MD/XLSX 报告 +│ └── other/ ← ZIP 等其他文件 +├── scripts/ ← 采集和处理脚本 +│ ├── fetch_all.py ← 全量消息拉取 +│ ├── extract_links.py ← 链接提取 +│ ├── build_graph.py ← 知识图谱构建 +│ ├── write_obsidian.py ← Obsidian 库生成 +│ └── daily_feishu_collector.py ← 每日定时采集脚本 +├── data/ ← 中间数据 +│ └── links/ ← 提取的链接列表 +└── docs/ ← 历史文档 +``` + +## 快速开始 + +### 环境要求 + +- Python 3.10+ +- 悟空 CLI(dws)已认证登录 +- Node.js(可选,用于 Playwright 浏览器模式) + +### 使用方式 + +```bash +# 1. 全量拉取两个群的消息 +python scripts/fetch_all.py + +# 2. 提取所有链接和文件 +python scripts/extract_links.py + +# 3. 构建知识图谱 +python scripts/build_graph.py + +# 4. 生成 Obsidian 知识库 +python scripts/write_obsidian.py + +# 5. 查看结果 +# 知识图谱:output/knowledge-graph/knowledge_graph.html +# Obsidian:用 Obsidian 打开 output/obsidian-vault/ 目录 +``` + +### 每日定时采集 + +```bash +# 注册 Windows 定时任务(每天18:00执行) +python scripts/daily_feishu_collector.py +``` + +## 核心发现 + +### 《我的花园世界》研究 + +详见 [output/reports/花园世界全量汇总.md](output/reports/花园世界全量汇总.md) + +**一句话结论**:不要学"种花题材",要学"已验证底座 + 放大能力"的立项路径。 + +### 知识图谱概览 + +- **28位活跃人员**:跨两个群 +- **190个飞书文档链接**:4个飞书空间 +- **18个文件附件**:HTML/MD/XLSX/PPT/PDF/ZIP +- **7大核心主题**:花园世界研究、云湖项目、Agent工具、战略思维、AI落地、创新组研发、战略组日报 +- **300+条关系** + +## 数据来源 + +| 群组 | 消息数 | 时间范围 | 飞书链接 | +|------|--------|----------|----------| +| dc战略问题研究院 | 291条 | 2026-05-08 ~ 06-02 | 96个 | +| 创新组 | 86条 | 2026-05-01 ~ 06-02 | 94个 | + +## 技术栈 + +- **悟空 CLI(dws)**:钉钉消息拉取、文件下载 +- **Python**:数据处理、知识图谱构建 +- **BeautifulSoup**:HTML 解析 +- **Obsidian**:知识库管理 \ No newline at end of file diff --git a/data/links/all_feishu_content.json b/data/links/all_feishu_content.json new file mode 100644 index 0000000..f21ec59 --- /dev/null +++ b/data/links/all_feishu_content.json @@ -0,0 +1,797 @@ +{ + "date": "2026-06-02", + "total": 113, + "documents": [ + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-06-02 03:15:57", + "url": "https://dianchukeji.feishu.cn/wiki/FYKlwX7D5ibbmSkaVMucgKAWnOe", + "content": "日报-王雨默输入“/”快速插入内容2026.6.1-日报-王雨默​用户2965用户2965今天修改一.工作内容概述​•使用 AI 分析《佛系消消消》的资源分包加载机制,结合本地缓存、运行日志和 Addressables catalog 文件,解析出关卡分包对应的 CDN bundle 地址,批量拉取主线 33 个关卡资源包并完成解包解析,提取主线普通关卡 3296 关,连同双牛模式、方块模式,总计整理 4452 关独立关卡数据。​•优化关卡生成器逻辑,提升其产出交付合规关卡的稳定性​•参与AI游戏开发交流会​二.《佛系消消消》关卡数据提取​利用AI对手机本地的《佛系消消消》包体资源进行了逆向分析和提取,目标是获取游戏中的完整关卡数据,并理解其关卡文件组织方式和加载逻辑。​前期已经通过解包确认,主包中只内置了第一批关卡LevelPart01,后续LevelPart02-33并没有直接存在于本地包体中。后续继续通过逆向解包、日志分析、本地缓存检查和 catalog 解析的方式,最终整理出游戏远程关卡分包的真实下载链路。​1.试错过程概述​一开始尝试从几个方向直接查找关卡数据:​•逆向解包主包,搜索LevelPart02-33;​•检查本地缓存目录,寻找已下载的分包文件;​•尝试抓包观察游戏运行时的资源请求;​•直接猜测服务器接口或资源路径。​但这些方式都没有直接得到完整关卡。​主要原因是:​1.主包中确实只包含LevelPart01;​2.后续关卡通过远程资源分包加载;​3.微信小游戏网络请求存在加密,普通抓包方式难以直接看到完整资源地址;​4.直接猜测服务器路径容易出现 404 或参数缺失。​因此后续思路调整为:不再直接搜索关卡文件,而是先还原游戏的远程资源加载链路。​​2.最终提取流程​2.1逆向解包主包,确认资源不完整​首先对游戏主包和 Unity 资源文件进行逆向解包分析。​解包后发现,主包中确实存在部分关卡文本和配置表,例如LevelPart01、LevelJsonBatchMap、LevelId、DailyLevel等。​但同时也确认了一点:主包中只注册和内置了第一批关卡,后续LevelPart02-33并不在主包内。​这说明完整关卡数据不是一次性打进本地包体,而是采用远程分包加载方式。​​2.2分析运行日志,寻找 CDN 入口​确认主包中没有完整关卡后,下" + }, + { + "group": "创新组", + "sender": "刘鹏", + "time": "2026-06-01 22:44:23", + "url": "https://dianchukeji.feishu.cn/wiki/PY6mwULmXiWbhEkpO3wcYjPCnrh", + "content": "日报-刘鹏输入“/”快速插入内容2026.06.01日报-刘鹏​用户2416用户2416昨天修改一、工作概述​1.数值调研启动​2.对后续任务进行重新规划​3.优化了一下UI编辑​二、主要产出​2.1-数值调研启动​1.调研以剧情阶段为节点,记录对应的订单、棋盘空间、生成器状态如何变化?​2.量化订单的需求物品和产出、剧情的金币需求和产出、棋盘空间的格子状态、当前物品链的等级解锁状态以及生成器当前的等级和产出​3.汇总分析:最后将这些数据汇总,让AI读取分析,同时会尝试去找现成的二合数值模板,结合起来参考分析,与AI商定数值框架,并进行标准数据测试、跑测等检测实现效果,并根据结果进行调整,直到数据测试达标、实际跑测体验达标。​订单表​25%剧情表​25%棋盘空间表​25%生产器表​25%2.2-对后续任务进行重新规划​重新明确两周后以项目上线为具体目标,与AI商讨调整的具体方案细节,具体化量化每天的产出目标。​1.剧情系统你想要做到哪一档:有章节推进、角色对话、阶段目标、若干关键剧情节点​2.基础功能系统需囊括:设置系统、存档系统、公告、账号登录​3.美术范围做到哪一层:具体的美术需求文档,菜单界面、设置界面、登录界面等​4.音效需求:明确具体有哪些音效的需求,包括主BGM、合成音效、点击/按钮音效、生成器产出音效、订单提交音效、奖励获得音效、剧情弹窗/文本推进音等,生成具体需求文档​5.可上线的目标:能提测,具备正式资源和基础功能​​33%​33%​33%2.3-UI编辑优化​问题:​•随着UI功能逐渐增多,读取加载的方式会显著拖慢项目的启动时间,影响功能测试效率​•同时UI编辑场景和运行场景分离不利于直接观察实际项目真实的UI布局​改动:​•将UI编辑功能转移到实际项目场景,便于直接观察实际项目真实的UI布局,减少来回导参数的成本​•UI的布局缩放等参数直接在编辑器定死,不再走配置加载,提高了检测效率​•保留配置导出功能,保留项目的回档能力。​" + }, + { + "group": "创新组", + "sender": "韦译", + "time": "2026-06-01 22:44:11", + "url": "https://dianchukeji.feishu.cn/wiki/PuiOw5HETi9pnekp6wlctOIvn0c", + "content": "日报-韦译输入“/”快速插入内容260601日报-韦译​用户6299用户6299昨天修改1.工作内容概述​1.参与AI游戏开发问题交流会,整理笔记和收获​2.调研拆解《浪漫餐厅》的关卡设计和数值设计规律:今天主要拆解了前15单的一个棋盘摆放规律​3.基础功能线——修复bug:点击生成器生成物品后,图标会错位的问题​4.商业化线——学习cocos UI多分辨率适配方法,完成多分辨率的初版开发​5.调研二合类游戏的数值模型​2.进度​2.1 参与AI游戏开发问题交流会,整理笔记和收获​2.1.1 AI配表问题​▪设计具体数值和表格字段​•设计的时候,可以跟AI来讨论数值设计。​•人管数值大方向和体验,AI来输出具体的数值​▪配表部分配表部分​•核心:配表的时候,重点是确定性,AI不能出一点错误,出错问题很大​•方法​◦方法一(较为稳健):AI出具体数值,人来配置,AI来检查​◦方法二:如果要AI来配,要保证准确性为100%​▪让AI用脚本来写入,不能直接填​▪原因:脚本是规范化程序,如果配得有问题,能够直接报错原因​▪不要让AI来配置表格的原因​•自己不去配表,全让AI配,整个表就是黑盒,很难排查问题​•AI配表还是有出错的概率,如果不是百分百对,就仍然有很大风险​▪源表格的选择​•yaml:ai好读好改,人好读,但不好改​•excel:目前这个阶段,还是尽量用excel​◦excel有mcp,AI也能直接改。但是最好不要让AI来配置表格​​🥥后续计划,根据以上学到的内容,改造自己的AI配表方案​2.1.2 AI编程问题​主要围绕架构设计展开​▪架构设计思路:​•架构和业务是要分开设计的,业务逻辑上要解耦,做成基于架构的设计的填空题​•架构设计在单一品类的游戏中,大概率是不变的,是具备高可复用性的。​◦案例:一套二合的游戏架构/mmo的游戏架构,能做很多个同类型的项目​▪设计架构的原则​•高可复用性:一个代码设计能够重复利用​◦例如:程序老师举的例子,在UI中只分层全屏弹窗、小弹窗、浮动组件3种UI。所有UI都能用这三种组件来构成开发。​•低耦合度:即各个系统互不影响,修改A系统不影响B系统​▪怎么学习和积累​•自己去网上学习相关内容​•找一款参考对标的游戏,自己设计一套架构,看看能否顺利复现,如果可以,就证明方向大概率是对的;如果不可以,则需要调整方向​•带着问题去拆" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-29 23:22:06", + "url": "https://dianchukeji.feishu.cn/wiki/EIWNwKjnIipmStkzIr1cd1kTnPf", + "content": "日报-王雨默输入“/”快速插入内容2026.5.29-日报-王雨默​用户2965用户29655月29日修改一.工作内容概述​•尝试优化AI自动化关卡生成逻辑​•尝试优化自动化关卡截图分析流程​•体验《佛系消消消》,补充收集部分关卡样本,作为后续分析参考。​二.关卡生成逻辑优化​1.目前关卡生成痛点​目前关卡生成的主要问题集中在高维度关卡,尤其是10x10、12x12这类关卡。​之前的生成方式更偏向先随机生成区域,再通过反复尝试来筛选合适结果。这种方式在低维度关卡上还可以接受,但在高维度关卡上会暴露出几个问题:​•很多关卡虽然能生成出来,但并不是唯一解;​•有些关卡看起来结构正常,但玩家实际推理时可能无法稳定解出;​•通过随机微调区域边界来修复多解问题,成功率很低;​•部分备用生成路径虽然能产出关卡,但质量不可控,不适合作为正式发布内容;​•原本的难度评估比较粗,只能大致判断关卡是否可解,不能很好反映推理过程到底有多复杂。​也就是说,当前关卡生成的核心问题不是“能不能生成出来”,而是生成出来的关卡是否满足正式发布要求:​•答案是否唯一;​•是否能通过逻辑推理解出;​•难度是否符合预期;​•生成过程是否足够稳定。​​2.优化逻辑​本次优化的方向,是把关卡生成从“随机尝试”调整为“围绕发布标准进行生成”。​也就是不再单纯追求生成数量,而是先明确一套正式关卡必须满足的标准:​•必须只有一个正确答案;​•必须能通过逻辑推理完成;​•普通关不能依赖猜测;​•高维度关卡允许使用更复杂的推理方式;​•备用生成结果不能直接进入正式发布流程;​•关卡难度不仅看尺寸和区域数量,也要看实际推理过程。​同时,对求解器的评分逻辑进行了优化。之前更多是判断“这关能不能解出来”,现在进一步补充“这关是怎么解出来的”、“用了多复杂的推理步骤”。​这样后续就可以更准确地区分:​•简单关:通过基础排除就能解出;​•中等关:需要结合行、列、区域关系进行判断;​•高难关:需要多步推理或组合判断才能解出。​​3.优化步骤​3.1 调整正式生成入口​将正式生成流程切换到更适合保证唯一解的生成方式。​之前的生成方式偏随机,适合快速产出候选关卡,但高维度关卡容易出现多解。​新的生成方式会在生成过程中不断检查并排除错误候选,目标是更稳定地生成只有一个答案的关卡。​这样做的目的,是优先保证关卡的正确性,再考虑生成效率。" + }, + { + "group": "创新组", + "sender": "刘鹏", + "time": "2026-05-29 21:27:07", + "url": "https://dianchukeji.feishu.cn/wiki/G5cPwiVSUiGzkrk2ZIzcP24hn0b", + "content": "日报-刘鹏输入“/”快速插入内容2026.05.29日报-刘鹏​用户2416用户2416昨天修改一、工作概述​1.优化拓展UI编辑器功能​2.同步优化UI风格和素材​​二、主要产出​2.1-UI编辑器优化​2.1.1-修复配置缓存失效问题​•问题:编辑器导出参数后,运行 Play Mode 或重新打开编辑器场景时,部分UI 布局没有变化​•原因:参数不匹配,在调整功能/新增UIicon等操作时,AI会为相应的功能和Icon做配置适配,这时会调整底层的配置,有时会修改名称/配置路径导致在UI编辑器界面读取时会存在功能性错位,从而使得布局没有正常加载​•方案:UIConfig.cs添加[InitializeOnEnterPlayMode]重置静态缓存;BuildInScene()开头调用UIConfig.Reload()确保读取最新配置。同时在功能制作的workflow节点添加UI编辑器功能同步节点,快速修复UI的功能性错位。​2.1.2-新增 Sprite/Icon 路径导出​•问题:编辑器只导出布局参数(位置、大小),更换 Image 组件的 sprite 后不会写入配置​•方案:新增ExportSprites()+GetResourcePath(),从 Image 组件读取当前 sprite,解析出Assets/Resources/相对路径写入UILayoutConfig.json的\"sprites\"节。​•好处:支持可视化的UIicon快速调整,不用每次都让AI同步一遍​2.1.3-Layout Group固定布局改为自由定位​•问题:AI为了确保UI的稳定性,避免功能调整或分辨率调整时,同模块的UI错乱会添加Layout Group来约束同一模块的UI组件,导致组件布局不可自由调整,例如底部按钮(Backpack/Shop/Tasks)使用HorizontalLayoutGroup,Layout Group 强制管理子物体位置,在 Scene 中无法单独移动​•方案:去掉 Layout Group,每个按钮改为独立 anchor 定位,Export 时逐按钮导出 anchor/offset。编辑器和运行时同步修改​2.1.4-订单奖励区改为自由定位​•问题:由于奖励icon+文本是列表性的组件UI,是通过脚本来动态加载位置的,因此如果要修改时就需要采用单独的样" + }, + { + "group": "创新组", + "sender": "韦译", + "time": "2026-05-29 21:01:23", + "url": "https://dianchukeji.feishu.cn/wiki/N4MdwTuQAiPyGRkHWJPcuyeInpf", + "content": "日报-韦译输入“/”快速插入内容260529日报-韦译​用户6299用户6299昨天修改1.工作内容概述​1.基础功能线——使用自动化批量关卡生成方案,复刻《庄园合合》的关卡:目前能够完整复刻前15个订单,以及部分棋盘的物品摆放​2.基础功能线——给自动化批量关卡生成方案,做了一个skill来一键启动​3.基础功能线——增加调试面板​4.基础功能线:关于生成器和物品的一些新功能​a.完成剧情节点时,除了经验,还会发放物品/生成器奖励,发放的奖励会进入新增按钮​b.达到第五等级的生成器,能够生成副链的物品​5.商业化线——完成新手引导流程的开发​6.美术线——继续生成新增物品链条的美术资源​7.美术线——每日UI审美提升训练​2.进度​2.1 基础功能线——使用自动化批量关卡生成方案,复刻《庄园合合》的关卡:目前能够完整复刻前15个订单,以及部分棋盘的物品摆放​◦参考昨天调研的结果,将生成器、物品一一映射到本项目中​◦目前效果对比《庄园合合》​▪复刻了订单相关的数值,例如订单物品、订单奖励的金币​▪还原部分棋盘上物品的摆放位置(还有部分还没解锁)​▪复刻新手引导教程​2.2 基础功能线——给自动化批量关卡生成方案,做了一个skill来一键启动​◦这个skill的效果:能够让AI自动跑通自动化批量关卡生成的完整流程​" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-29 00:09:28", + "url": "https://dianchukeji.feishu.cn/wiki/BGn2w5h1Vi8LVWkSzwbcp4xKnNf", + "content": "日报-王雨默输入“/”快速插入内容2026.5.28-日报-王雨默​用户2965用户29655月29日修改一.工作内容概述​•优化棋盘交互体验、优化提示系统逻辑​•修复广告按钮可以快速点击、重复发送广告请求的问题​•尝试使用 AI 调用现有关卡生成器 API,初步验证 AI 是否能够自动调用项目工具,并按照预设目标控制关卡难度曲线​•收集《佛系消消消》部分关卡数据,尝试使用 AI 对其进行结构化整理与分析,初步验证 AI 辅助分析外部关卡设计的可行性​​二.AI生成关卡尝试​尝试使用 AI 调用现有的关卡生成器 API,进行自动生成关卡的初步测试。本次测试的重点并不是单纯追求最终生成多少可用关卡,而是验证 AI 是否能够理解并调用项目中已有的工具链,包括生成器参数配置、批量生成、结果校验、状态流转和资源导出等流程。​测试中,初步以 50 关为目标进行生成尝试,并按照预设的难度曲线进行规划。整体设计思路是每 5 关作为一个小波次,通过“逐步爬坡 + 阶段卡点”的方式,让关卡难度在前期逐步上升,同时在固定节点提供一定挑战。通过这种方式,可以初步验证 AI 是否能够不只是机械调用生成接口,而是根据关卡节奏目标组织生成参数,并尝试控制整体难度变化。​在生成流程中,也尝试加入目标难度参数,用于约束目标关卡的逻辑复杂度。AI 根据不同关卡阶段传入对应的参数范围,生成器再基于该范围筛选候选关卡。这样可以让生成流程具备一定的难度控制能力,而不是完全依赖随机生成结果。​本次测试中,AI 基本能够完成以下流程:​•根据预设关卡数量和难度节奏组织生成任务;​•调用现有关卡生成器 API 批量生成关卡;​•根据生成结果进行基础校验和筛选;​•将生成出的关卡状态流转到可发布状态;​•导出到游戏运行时使用的关卡资源目录;​•清理运行时不需要的推导记录、推导画像等冗余字段,降低资源体积。​​不过在测试过程中也发现,当前流程距离稳定自动化生成仍有一定差距。主要问题包括:​1.即使让 AI 负责设置生成参数,高维棋盘关卡的生成成功率仍不稳定,需要花费较多时间重试。​2.回退的生成算法虽然能够提高生成成功率,但对难度范围的控制较弱,导致生成结果波动较大。​3.部分预设难度区间过窄,当前生成器命中率不高,导致部分关卡需要大量重试,甚至出现生成失败的情况。​4.当前难度曲线更多是基于设计目标设定,后续还需" + }, + { + "group": "创新组", + "sender": "韦译", + "time": "2026-05-28 22:39:42", + "url": "https://dianchukeji.feishu.cn/wiki/FVJ6w0RZFirH9tk7uA4ctqQTn1d", + "content": "日报-韦译输入“/”快速插入内容260528日报-韦译​用户6299用户62995月28日修改1.工作内容概述​1.基础功能线——完善自动化批量关卡生成方案:目前能够跑通从关卡设计和数值设计开始,到AI配置的整个闭环​2.基础功能线——调研竞品《庄园合合》的关卡设计和数值设计:工作量比较大,预计还需要1天完成​3.基础功能线——根据目前调研出来的《庄园合合》的关卡和数值,使用自动化批量关卡生成方案,复刻到当前游戏中:目前遇到一些小bug,预计明日完成​4.基础功能线——新增物品合成链,满足游玩内容扩充的需求​5.基础功能线——新增生成器合并功能(之前不能合并)​6.美术线——生成新的物品合成链的美术资源​7.美术线——每日UI审美积累​2.进度​2.1 完善自动化批量关卡生成方案​◦新增了规则层自动落表功能:规则不再默认靠人工手写,改成由 AI 根据讨论结果生成规则层 YAML /配置,再交给算法校验。​◦新增了 chapter skeleton 自动生成功能:章节骨架不再要求人工先写,改成 AI 先生成章节骨架,再往下展开关卡。​◦新增了 slice 批量生成功能:AI 按章节骨架批量生成每个小关卡配置,而不是一关一关手工落表。​◦新增了自动校验功能:覆盖 schema 校验、引用合法性、交叉一致性、难度校验、供给校验、棋盘耦合校验等。​◦新增了自动修复 / 重生功能:校验不过时,不是直接人工返工,而是把错误报告回喂给 AI,让 AI 自​动修复或重生成。​2.2 调研竞品《庄园合合》的关卡设计和数值设计​◦目前的调研方法为:​▪我拆解并记录游戏中的关键数据和数值,列为表格​▪给AI游戏规则,让它用这些数据和数值去纸面模拟、数值推演​▪让AI总结这些数据和数值的规律​◦关键数据和数值记录​▪订单奖励金币​▪订单目标物品​" + }, + { + "group": "创新组", + "sender": "刘鹏", + "time": "2026-05-28 22:30:28", + "url": "https://dianchukeji.feishu.cn/wiki/HVxhwFfM2idMx7kTiuBcgVBXnCb", + "content": "日报-刘鹏输入“/”快速插入内容2026.05.28日报-刘鹏​用户2416用户24165月28日修改一、工作概述​1.完成UI编辑器细调功能​2.对现有订单、棋盘的UI和功能逻辑进行优化​3.优化了一下体验阶段参数生成器的流程逻辑​​二、主要产出​2.1-完成UI编辑器细调功能​2.1.1-开发目的​最后的百米冲刺:在早期使用AI完成UI布局时,发现AI能够通过识别草图/详细的描述来完成80%的UI布局,剩下的20%,要么需要非常精确的原型图,要么存在自然语言难以描述或描述困难繁琐的情况,例如单个订单的UI就包括人物icon、物品栏背景、物品格子、物品、提交按钮、奖励面板、奖励icon以及奖励数量等这些UI元素的位置、缩放和逻辑。纯使用自然语言或原型图来完成会比较费时间,且后续调整的时间成本也比较高,最快的办法自然是自己上手直接调,所以会选择制作这样一个功能,来完成细节的调整​2.1.2-主要功能​1.编辑调整:在 Unity 编辑模式下,借助Unity编辑器本身的UI调整功能,对视图窗口中的UI组件进行缩放、拖动等,直接把游戏里的整套 UI 搭出来。​2.快速配置:UI搭好后,可快速导出UI的配置参数,系统会把当前 UI 的位置、尺寸、间距、棋盘参数、部分缩放参数写回配置文件,快速完成配置同步,且可直接运行项目测试。​3.同步数据:由于共用同一套配置文件,每次重新打开配置窗口时,会自动按配置把编辑器界面重新搭出来,直接在现有的UI界面上改动,确保UI数据同步。​4.可配置:棋盘现在也支持通过配置控制,保留AI可直接通过修改配置来调整UI​包括:​◦棋盘区域上下位置​◦棋盘内部 padding​◦格子大小​◦格子间距​◦整组格子的起始偏移位置​2.1.3-运行状态​2.2-对现有订单和棋盘的UI以及功能逻辑进行优化​2.2.1-订单模块​1.订单提交物品过滤— 只有未被遮挡的物品才能用于订单判定和提交,半遮挡/全遮挡的物品不计入。​2.订单人物icon去重— 同时显示的订单不会出现相同的人物头像,从8个人物池中无重复抽取。​3.订单人物icon保持— 提交订单后,未完成的订单保留原有人物icon不变,只有新补充的订单才随机分配新人物。​2.2.2-棋盘模块​生成器合成和移动功能 —增加生成器的移动拖拽和同名合成功能。​2.3-对体验阶段参数生成器做了优化​项目​原" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-28 01:20:32", + "url": "https://dianchukeji.feishu.cn/wiki/Hv4uwS6U9iqN1skMIKIczOgAnKb", + "content": "日报-王雨默输入“/”快速插入内容2026.5.27-日报-王雨默​用户2965用户29655月28日修改一.工作内容概述​•基本完成项目主要系统界面的多分辨率适配逻辑梳理与落地调整。​•尝试使用 OpenClaw 自动收集整理抖音平台上《佛系消消消》的关卡数据,并验证视频反向提取方案的可行性。​​二.多分辨率适配相关​经过一天的尝试、排查和反复验证,基本完成了当前项目各主要系统的 UI 适配逻辑梳理,包括局内界面、主菜单、碎片收集面板、结算弹窗、通用弹窗、背景层以及部分特殊交互节点的适配处理。​本次适配工作的重点不只是修复单个界面的显示问题,而是对项目整体 UI 结构进行了一次重新整理。由于早期 UI 制作阶段没有针对多分辨率适配制定统一层级规范,部分界面中背景、内容、按钮、弹窗、交互区域混在同一套节点层级中,导致后续适配时容易出现互相影响的问题。​因此今日在实际试错的基础上,基本完成主要系统的适配逻辑梳理与落地调整,并总结出一套后续可以继续沿用的 UI 层级规范和适配思路。​​1.最终确定的 UI 层级规范与适配思路​当前阶段确定的整体原则是:背景独立处理,内容按区域分组,交互节点单独维护,弹窗使用独立规则。​UI 层级规范​统一按照背景层、顶部区域、主内容区域、底部操作区域、弹窗层进行组织,不同层级分别承担铺满、展示、交互和覆盖职责,避免所有节点共用同一套缩放链路。​这种分层方式可以让不同类型的 UI 使用不同适配策略,避免背景、内容、交互和弹窗互相影响,降低后续维护成本。​​适配思路​•背景层:采用独立铺满策略,根据实际可见区域动态拉伸,保证不同屏幕比例下不会出现留白或裁切。​•普通 UI 内容:优先按照功能区域进行分组,例如顶部组、内容组、底部组。运行时主要调整分组容器的位置和缩放,尽量保留编辑器中已经确定好的子节点相对关系,避免代码逐个硬编码子节点坐标。​•棋盘网格、可点击格子等带有交互逻辑的节点:需要单独维护适配逻辑。此类节点不能简单跟随父级整体缩放,否则可能导致视觉位置和点击命中区域不一致。​•弹窗类 UI:不直接套用主场景适配规则。弹窗的目标是完整显示、居中展示和保证可交互,因此统一采用遮罩铺满、主体居中、超框缩小的方向。​​2.思考与复盘​通过今天的适配工作,比较明确地暴露出前期 UI 结构上的问题:如果一开始没有制定层级规范,后期再做多分辨率适" + }, + { + "group": "创新组", + "sender": "刘鹏", + "time": "2026-05-27 22:05:15", + "url": "https://dianchukeji.feishu.cn/wiki/Qn6Cw8OgmiBohUkweYCcPnLpnLb", + "content": "日报-刘鹏输入“/”快速插入内容2026.05.27日报-刘鹏​用户2416用户24165月27日修改一、工作概述​1.完成新手三步引导系统和单元测试系统​2.完成AI根据需求生成阶段性体验参数工作流​二、主要产出​2.1-完成新手三步引导系统和单元测试系统​使用workflow跑了一下昨天与AI一同设计的并行功能开发的工作流,同时去实现新手引导系统和单元测试系统。​1.使用差异:​•节点确认:会按照脚本在固定的节点进行预设询问,而不是让claude自行决定是否要询问你,询问哪些内容。​•分支逻辑:可运行单独的分支循环,例如“新手引导系统“进行到功能验收时会固定进行询问预设的选项,修复后也会再次询问直到最终通过。​2.最终测试结论:​•稳定性与智能牺牲:workflow通过脚本约束claude,以让AI完成稳定的工作产出,这个过程会牺牲掉部分AI的智能,也会存在工作流出问题以后,AI不会自行调整的问题。所以整体上是往稳定工作流方向专精的工作模式,应用场景比较有限。​•固有限制:workflow只会在会话开始时执行一次,后续产生上下文压缩以后,会直接遗忘当前节点转为普通对话,因此需要进行以下节点记忆强化,此方法能大幅解决节点遗忘和跳过的情况。​2.1.1-新手引导系统​核心思路:按步骤引导玩家完成第一轮核心操作(点击→合并→交付订单)。​要点:​1.配置驱动— 所有引导步骤定义在GuideConfig.json,每步包含:动作类型(click/drag_merge)、目标ID、高亮样式、对话文本、触发条件​2.三步流程— ①点击矿堆生产 → ②拖拽合并升级 → ③交付订单赚钱​3.条件触发— 不是无脑下一步,而是等条件满足(如棋盘上有2个同类物品)才显示合并引导​4.遮罩聚焦— 用四块黑色半透明遮罩把目标区域\"挖出来\",强迫玩家只能点高亮区域​5.高亮动画— 两种效果:circle_pulse(呼吸缩放)用于点击目标,arrow_drag(来回移动指示器)用于合并操作​6.完成记录— 用 PlayerPrefs 存guide_completed=1,下次启动不再触发​7.可重置— 调ResetGuide()清除记录,下次 Init 重新开始​2.1.2-单元测试系统​核心思路:把纯逻辑代码抽到静态类,用测试工具直接跑一遍测试正确性,不需要启动 Unity 场景。​好处" + }, + { + "group": "创新组", + "sender": "韦译", + "time": "2026-05-27 22:01:25", + "url": "https://dianchukeji.feishu.cn/wiki/Xd60wq12vi5tAUkx1NmcZdE4nrc", + "content": "日报-韦译输入“/”快速插入内容260527日报-韦译​用户6299用户62995月28日修改1.工作内容概述​1.基础功能线——实现自动化批量关卡生成方案的完整流程:目前能够完成跑通关卡自动生成的流程,每个流程步骤都可以追溯​2.基础功能线——优化UI:​a.优化了局外主界面的UI和局内游戏界面的UI。参考《浪漫餐厅》,去除了多余的信息​b.给关键UI信息、功能按钮生成了统一的美术资源底图​3.美术线——针对提升UI审美,搜集了一些UI设计网站,后续进行针对性地审美提升练习​4.整理出了问题清单​2.进度​2.1 实现自动化批量关卡生成方案的完整流程​◦当前的进度:目前能够完成跑通关卡自动生成的流程,每个流程步骤都可以追溯​👍•关卡自动生成的流程​第一步:人工与 AI 讨论规则层目标和体验原则​第二步:AI 写规则层配置,算法自动校验与编译​第三步:人工与 AI 讨论章节体验方向​第四步:AI 拆解每一章为多个小关卡(slice),并配置好关卡数值​第五步:算法校验、打报告、过滤不合格项​第六步:AI 根据错误与报告自动修复​第七步:人工查看数值、说明、风险报告,并进入试玩验收​🥥目前的整个流程都是在codex中跑通的,切换到任意的agent编程工具,都可以跑。后续计划做成skill或者workflow​◦以下举例​▪第一步:人工与 AI 讨论规则层目标和体验原则​▪第二步:AI 写规则层配置,算法自动校验与编译​▪第三步:人工与 AI 讨论章节体验方向​▪第四步:AI 拆解每一章为多个小关卡(slice),并配置好关卡数值​▪第五步:算法校验、打报告、过滤不合格项​▪第六步:AI 根据错误与报告自动修复​▪第七步:人工查看数值、说明、风险报告,并进入试玩验收​•这个是由人来完成并反馈的​" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-27 00:30:53", + "url": "https://dianchukeji.feishu.cn/wiki/Y42iwXAsXigSyfkF6bXc5UkLnyb", + "content": "日报-王雨默输入“/”快速插入内容2026.5.26-日报-王雨默​用户2965用户29655月27日修改一.工作内容概述​•产出剩余系统所需美术资源,并完成项目内替换​•学习 Cocos 多分辨率适配方法,理解 Canvas、Widget、UITransform 等相关组件的作用,并初步对部分界面尝试进行适配调整。​​二.多分辨率适配知识梳理​1.多分辨率适配原理思路​多分辨率适配并不是单纯地把 UI 等比例缩放到不同屏幕上,而是要在不同设备宽高比下,保证核心内容可见、界面布局稳定、交互区域合理,并尽量避免 UI 被裁切、留黑边或位置错乱的问题。​Cocos 中多分辨率适配的核心,可以理解为“以设计分辨率为基准,在真实设备屏幕上重新映射显示区域”。​设计分辨率相当于开发时使用的一套标准画布尺寸,例如按照1080×1920来搭建界面。但在不同的设备下,屏幕分辨率和宽高比并不总会保持统一,因此运行时需要根据设备屏幕尺寸,对 UI 进行缩放与布局调整。​Cocos 的 Canvas 会基于设计分辨率和当前设备屏幕尺寸,计算 UI 在真实屏幕中的显示区域与缩放关系。​适配中比较关键的是 Fit Width 和 Fit Height。它们本质上决定了设计分辨率如何映射到真实屏幕,不同组合会影响 UI 的缩放比例和最终可视区域。​•Fit Width:优先保证设计宽度与屏幕宽度匹配,适合宽度方向布局较敏感的界面。​•Fit Height:优先保证设计高度与屏幕高度匹配,适合高度方向内容较重要的界面。​•组合使用时,需要结合实际设备比例进行验证,避免出现内容过度缩放、边缘留白或局部裁切。​因此,实际项目中不能对所有界面使用同一种适配策略。背景类资源更关注铺满屏幕,必要时允许边缘裁切;核心玩法区域、按钮和交互内容则更关注完整可见和布局稳定。而且不能只看某一种分辨率下的表现,而是需要同时考虑窄屏、宽屏、全面屏、平板等不同设备比例下的显示效果。​48%52%​​​2.相关节点与组件理解​Canvas​Canvas 是 UI 适配的基础节点,主要负责整体显示区域和缩放策略。通常 UI 节点都会放在 Canvas 下,由 Canvas 统一管理它们在不同分辨率下的显示。​在项目中,Canvas 更适合处理“整体层级”的适配问题,例如:​•当前界面以什么设计分辨率为基准;​•整个 UI 是" + }, + { + "group": "创新组", + "sender": "刘鹏", + "time": "2026-05-26 22:30:51", + "url": "https://dianchukeji.feishu.cn/wiki/CDoOwO5ppif43Ak6Lx9cWGMensf", + "content": "日报-刘鹏输入“/”快速插入内容2026.05.26日报-刘鹏​用户2416用户24165月26日修改一、 工作概述:​1.对项目进行打包,在开发者工具上测试广告系统​2.完成测试埋点,并能够正常接入Game Analytics平台进行数据同步​3.探索新的AI agent工作模式——WorkFlow​二、主要产出​2.1-项目打包与广告系统测试​目前已完成项目打包,并在微信开发者平台完成了项目运行测试​测试结果:​1.项目可正常完成微信小游戏的转包,并且可在开发者平台正常运行​2.可正常完成广告播放(真实广告需要后续接入广告位测试)和基础的玩法交互,无报错​3.UI存在适配问题,部分UI存在布局位置不对的情况,主要是引擎和测试机的分辨率存在差异,需要在引擎端做动态分辨率UI适配。​2.2-测试埋点与GA平台测试数据同步​核心实现​•7 个埋点事件:game_start、merge_success、order_complete、ad_trigger、ad_complete、generator_click、session_end​•Provider 架构:IAnalyticsProvider接口 +ConsoleAnalyticsProvider(本地日志)+GameAnalyticsProvider(GA 平台)​•GA SDK 7.10.6:本地包引用,WebGL 平台 Keys 通过GASetup.cs编辑器脚本配置​微信小游戏适配​•crypto-polyfill.js— 补全微信环境缺失的 crypto API​•local-server.js— 本地 HTTP 服务器提供 >30MB 资源包​•post-export-local.ps1— 每次导出后自动修补 DATA_CDN、注入 polyfill、关闭 urlCheck​•微信开发者工具代理设置为\"使用系统代理\",确保 GA API 可达​数据验证​GA 后台 Real-time 已确认收到同步数据,埋点链路完整打通。​微信开发者工具运行结果​33%GA后台数据​​33%GA图表数据​33%2.3-WorkFlow探索​•最近了解一个新的AI工作模式,叫“claude code work flow”,作用是让claude严格按预定好的工作流节点去做完成任务,不会忘记执行步骤,可复用性强,并且支持可视化编" + }, + { + "group": "创新组", + "sender": "韦译", + "time": "2026-05-26 22:09:01", + "url": "https://dianchukeji.feishu.cn/wiki/SuymwQjFYimgnRkZRePcIW0PnWe", + "content": "日报-韦译输入“/”快速插入内容260526日报-韦译​用户6299用户62995月26日修改1.工作内容概述​1.基础功能线:完成UI的重构,总结了踩坑经验​2.基础功能线:实现关卡剧情推进​3.基础功能线:实现自动化批量关卡生成方案的部分,目前能够生成第一批关卡进行游玩​4.商业化线——接入数据埋点:熟悉并且理清了GameAnalytics平台的操作流程,能够把接入的事件埋点展示成可视化图表​2.进度​2.1 完成UI的重构,总结了踩坑经验​2.2 实现关卡剧情任务推进​◦目前实现的功能​▪可配置剧情任务​▪玩家可消耗金币完成剧情任务,获得奖励(目前奖励暂时配置的是经验,后续会配置物品和合成器)​▪可以在局内主场景中点击剧情按钮触发,也可以在主界面点击剧情任务触发​2.3 实现自动化批量关卡生成方案的部分,目前能够生成第一批关卡进行游玩​以下这方案是怎么自动化批量生成的​◦3个核心概念:​▪《浪漫餐厅》的长关卡主棋盘​•玩家始终在同一张主棋盘上玩,不切棋盘,不是一关一关地跳。变化发生在“这一阶段让玩家做什么、解锁什么、承受什么压力”————所以不能按照传统的关卡制度来划分关卡,而应该定义Slice​▪Slice​•slice 可以理解成“长关卡里的一个推进片段”。它不是一关新地图,而是这张主棋盘上的一个阶段控制单元。​•一个 slice 主要定义 4 件事:​◦这一段对应哪些订单​◦这一段允许哪些物品链/生成器参与​◦这一段对应哪段剧情推进​◦这一段的定位是什么,比如 intro新手关 reward 奖励关​▪方案一和方案二的分工​•方案一:关卡设计模板化与数值规律化方案​◦定义规则:也就是“slice 应该怎样被设计出来”​•方案二:AI批量生成关卡执行方案​◦执行生成,AI按照slice的要求,生成具体要求,配置数据到游戏中​◦自动化生成关卡的流程​▪先人工定义章节目标:首章要做成一个 20 个订单的长关卡阶段。​▪方案一把章节拆成 slice​•不是直接设计 20 个孤立订单,而是先决定:​◦要分成几个 slice​◦每个 slice 承担什么节奏职责​◦每个 slice 对应什么剧情推进​▪方案二根据这些 slice 去生成具体内容​" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-26 00:17:36", + "url": "https://dianchukeji.feishu.cn/wiki/Mx4SwTP4HiQNISkrygQcGk9jnIe", + "content": "日报-王雨默输入“/”快速插入内容2026.5.25-日报-王雨默​用户2965用户29655月26日修改一.工作内容概述​•皮肤面板、碎片收集面板UI美术资源产出、替换​•修复替换过程发现的一些缺陷与bug​•了解Claude Code Workflow功能,并尝试用其进行完整的项目代码审查、修改、验证任务。​​二.Claude Code Workflow 相关​1.概念​Claude Code Workflow 是 Claude Code 最近更新的一种面向复杂开发任务的流程化执行方式。它通过阶段拆解、任务委托、能力复用和验证闭环,将 Claude Code 从“单次回答问题”扩展为“持续推进任务”的开发协作模式。对于代码审查、项目整改、批量重构、测试补充、自动化验证等任务,Workflow 能够提供更清晰的执行路径和更稳定的过程控制。​2.启用方式​1.确保Claude Code版本大于等于v2.1.147​2.终端命令行输入:​◦macOS / Linux / WSL / Git Bash:export CLAUDE_CODE_WORKFLOWS=1​◦Windows CMD:set CLAUDE_CODE_WORKFLOWS=1​◦Windows PowerShell:$env:CLAUDE_CODE_WORKFLOWS=\"1\"​3.启动Claude Code,使用ultrawork关键词,即可使用Claude Code的Workflow功能​字体变为彩色即为成功​3.尝试记录​项目框架分析​尝试使用 Workflow 对项目进行整体代码框架分析。接到需求后,Claude Code将 Workflow 拆成了三个阶段:​•Structure 阶段:分析项目结构、核心模块、依赖关系​•Quality 阶段:并行分析代码质量、错误处理、可维护性​•Report 阶段:生成综合分析报告​从执行过程来看,Workflow 会按照预设阶段依次推进。Structure 阶段先分析项目结构,完成后再进入 Quality 阶段,最后生成 Report。​完成后,给出了项目概述以及发现的主要问题。从这次分析可以看到,Workflow不会只停留在单点分析,而是能够把结构、质量、问题、建议整合成一个完整结果。​" + }, + { + "group": "创新组", + "sender": "韦译", + "time": "2026-05-25 22:30:17", + "url": "https://dianchukeji.feishu.cn/wiki/HuUIwA39fi3UsqkdfhTcE9hRnde", + "content": "工作内容概述​1.修复UI严重卡住开发进度:今天使用Claude修改UI,但是错误很多,严重拖延了今天的开发进度,对此进行了一波反思​2.自动化批量关卡生成方案较为复杂,今天仍然在跟AI讨论。预计明天进行实现,生成第一批关卡​3.基础功能线:完成体力限制的生成器生成机制​4.基础功能线:新增动画——完成订单时,订单缩小并退出​2.进度​2.1 修复UI严重卡住开发进度​◦修复情况:​▪今天把原来的棋盘从7x7修改为7x9,对标浪漫餐厅。​▪但是棋盘变高,超出了原有大小。所以我希望对棋盘的位置进行微调,但是棋盘格子无法在编辑器的预览界面中进行预览。​▪于是我让Claude在编辑器预览中,新增棋盘格子节点,绑定游戏内的棋盘格子。但是效果很差。​•棋盘格子的美术样式跟之前的相比,差距很大,不美观​•同时claude修改后,bug非常多,整个游戏无法进行游玩。经常是改了A就会出现B,改了B就会出现C。整体开发效率非常低。​" + }, + { + "group": "创新组", + "sender": "刘鹏", + "time": "2026-05-25 22:29:38", + "url": "https://dianchukeji.feishu.cn/wiki/KoXGwnkJaiO7q8kah6WcAGmvn0l", + "content": "日报-刘鹏输入“/”快速插入内容2026.05.25日报-刘鹏​用户2416用户24165月26日修改一、工作概述​1.在原型图UI框架基础上尝试导入包装素材进行UI配置测试​2.完成合并的反馈的效果优化以及订单列表滑动显示功能​3.完成项目接入广告的功能实现和验证​二、主要产出​2.1-导入包装素材进行UI配置测试​在完成基础原型图的基础上,尝试导入UI素材,并让claude自行按照ID对应界面中已经存在的UI进行配置,精确度在90%以上,主要受到命名规则的影响,以及素材ID和UI的ID数量是否一一对应。​2.1.1-以下是两种错误判定的具体情况:​1.素材ID和组件ID无联系/联系较弱,例如:素材命名为board,但组件中存在多个board,例如cell_board、order_board等,则AI极大可能无法进行精确配置​2.素材ID和UI的ID数量不是一一对应的,例如UI组件有一个character配置,但素材中有多个character,可能出现配置错误,多个UI组件对应少量素材配置时,只要名称对应,通常不会有错。​2.2.2-避免方法:​1.精确命名,在Schema中统一好命名的规则​2.输入系统提示词,让AI在配置时遇到多对一情况时,询问处理方式,避免其自行决断导致配置出错。​​2.2-完成合并的反馈的效果优化以及订单列表滑动显示功能​实现物品点击和合并后的缩放功能,提供明显的操作反馈,同时增加订单列表的滑动功能,随着后续合成链数量增多后,可适配更多的订单显示需求,同时同一时间显示的订单数量控制在3个,减少多订单目标对用户的信息干扰。​​2.3-完成广告系统的开发和功能验证​2.3.1-广告触发调用流程​广告位配置(3个)​触发入口​1.自动触发TryTriggerAd(placementId)​◦OnStaminaChanged→ 体力≤0时触发ad_generator_speedup​◦OnBoardWarning/OnItemPlaced→ 棋盘接近满时触发ad_clean_board(当前已暂停)​2.主动请求TryRequestAd(placementId, onWatched, onSkipped)​◦由业务方(如订单提交)手动调用,传入成功/跳过回调​◦用于ad_order_multiplier​触发保护机制​•冷却时间:触发后 30s /" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-23 00:57:23", + "url": "https://dianchukeji.feishu.cn/wiki/Bf4mwuFU9in51RksjDDc5Fdgnag", + "content": "日报-王雨默输入“/”快速插入内容2026.5.22-日报-王雨默​用户2965用户29655月23日修改一.工作内容概述​•参与工作流分享汇报​•继续产出UI资产,完善局内界面美术表现,已完成各模式玩法局内主界面的资产替换,以及棋盘单元格资源替换;​•同步优化细节表现,增加单元格交互震动功能​​二.通用性资源生成与九宫格复用尝试​在继续产出局内 UI 资产的过程中,发现部分按钮、底板类资源存在尺寸相近、风格相似的问题,浪费空间,因此开始尝试将这类素材抽象为通用底板资源。​核心思路是:​•尽量去除强绑定内容,比如复杂纹路图案、不可复用装饰等;​•保留通用的边框、底色、材质等;​•可以通过九宫格拉伸适配不同尺寸;​•让同一张资源可以应用到按钮、面板、棋盘单元格或其他 UI 容器中。​这样做的好处比较明确:一方面可以提升资源复用率,减少不同尺寸、不同场景下重复生成相似资源的情况;另一方面也能降低包体大小压力,避免大量近似 UI 资源同时进入项目。​​​三.Codex 内置生图工具的小规模角色资产测试​尝试使用 Codex 内置生图能力进行角色类资产绘制,主要测试方向是小规模角色资产的生成效果。​从目前结果看,Codex 在这类任务上有几个比较明显的优点:​•对简单明确的角色需求理解较好;​•在美术风格有明确规范下,风格一致性保持较好,产出效率高;​•生成结果经过去背景、切分、压缩处理后,即可进入项目资产库。​从流程上看,这种方式比较适合用于小规模资产补充,而不是一次性生成复杂界面或大量强结构化 UI 元素。​给Codex的参考图​55%与其聊天确认形象方案​45%皮肤入口icon​提示道具icon​23%抽奖入口icon​揭示道具icon​24%个人信息icon​清除标记icon​24%坐标显示icon​29%​四.后续计划​•产出剩余各系统界面、弹窗界面的美术资产,并完成替换​•持续优化细节表现​•体验《佛系消消消》,总结其关卡设计、节奏控制与投放思路;​•基于体验结果重新生成并配置关卡,必要时扩充关卡编辑器功能。​•持续进行真机测试,排查平台适配问题​" + }, + { + "group": "创新组", + "sender": "韦译", + "time": "2026-05-22 22:39:12", + "url": "https://dianchukeji.feishu.cn/wiki/DcOkwuOj6iPvdWkaFD1clKuRnAB", + "content": "工作内容概述​1.基础功能线——完成w2要求的初版关卡和数值设计,玩家能够正常游玩前20个订单​2.基础功能线——研究自动化批量关卡生成方案​3.商业化线—— 广告接入:尝试在开发者工具中进行广告测试,但是遇到资格问题​4.商业化线——接入数据埋点:跑通了游戏数据分析平台 GameAnalytics的流程,大部分埋点成功生效并显示​5.基础功能线——按玩家成长进度解锁生成器,通过新增按钮添加生成器到棋盘中​6.在接入微信开发者工具时测试广告时,发现切换分辨率后,UI会乱。调查后发现是之前的UI开发不规范导致的,目前正在重构UI​2.进度​2.1 基础功能线——完成w2要求的初版关卡和数值设计,玩家能够正常游玩前20个订单​◦根据w2-1要求的数值,设计了一批初始的订单,难度逐步提升​◦同时,后续新增了根据玩家进度解锁新的生成器的功能,整个玩法循环初步建立起来​▪通过二合交付订单——>金币增长——>解锁新的生成器——>解锁新的物品链,能够二合新的物品——>能够交付高难度的订单​2.2 基础功能线——研究自动化批量关卡生成方案​◦跟AI讨论了比较长的时间,主要从以下几个需求来设计整个方案​▪尽量减少人工的参与度​▪使用算法来生成关卡​▪使用AI来配置关卡数据​◦整个自动化批量关卡生成方案的设计如下​​人工设计关卡模板​↓​算法参数化生成关卡​↓​通过脚本、算法,计算关卡难度​↓​AI 辅助生成 / 修改 YAML 配置​↓​Schema + 构建脚本校验​↓​人工试玩验收​​◦这样设计的优势:人工来把握保证关卡设计的大方向不跑偏,但是通过算法生成+AI配置+人工校验​2.3 商业化线—— 广告接入:尝试在开发者工具中进行广告测试,但是遇到资格问题​◦经过调研和实践,发现如果想测试广告位是否生效,必定需要广告位ID。但是只有微信流量主才能申请广告位ID,而达成流量主的条件比较麻烦,需要小游戏至少有1000人的用户量。门槛较高。​▪通过跟网上的微信小游戏开发者交谈,如果想要测试广告位的话,可能需要去咸鱼二手平台上购买别人的流量主账号,否则就几乎只能等小游戏上架后获得1000用户量​▪后续打算尝试咸鱼购买账号这条野路子​" + }, + { + "group": "创新组", + "sender": "刘鹏", + "time": "2026-05-22 22:29:44", + "url": "https://dianchukeji.feishu.cn/wiki/VCZAwd24fiQIHdk9nrdcKR9TnWg", + "content": "日报-刘鹏输入“/”快速插入内容2026.05.22日报-刘鹏​用户2416用户24165月22日修改一、工作概述​1.完成订单系统和美术的基础包装​2.借鉴同组成员的工作流,对自身的原工作流做调整​​二、主要产出​2.1-完成订单系统和基础包装​2.1.1-订单系统:​订单系统运作逻辑​数据层:一个订单长什么样​OrderData.cs 定义了订单结构:​核心逻辑:OrderManager 做了什么​OrderManager.cs 是单例,负责全部订单逻辑:​1. 初始化时订阅棋盘事件​代码块​Plain TextBoardEvents.OnMergeSuccess → 记录玩家最高合成等级​2. 检查是否能交付(CanFulfillOrder)​遍历棋盘所有格子,统计每种物品数量,对比订单所需 — 全部满足则可交付。​3. 提交订单(TrySubmitOrder)​代码块​Plain Text检查能否交付 → 从棋盘移除对应物品 → 发放金币/经验 → 标记完成 → 刷新新订单​UI层:OrderUI 做了什么​OrderUI.cs:​•最多显示3 个订单卡片​•每张卡片布局:左侧人物头像 | 右上方奖励(金币/经验)| 右下方所需物品格子 + 交付按钮​•每0.5 秒检查一次棋盘状态,更新按钮可否点击(橙色=可交付,灰色=物品不足)​•点击\"交付\"→ 调用OrderManager.TrySubmitOrder​•订单完成后弹出奖励横幅(2.5秒后消失)​完整链路总结​代码块​Plain TextJSON配置加载 → ConfigManager缓存所有OrderData​↓​OrderManager.Init() → 根据权重+难度+前置条件 选出3个活跃订单​↓​玩家在棋盘合并物品 → OnMergeSuccess更新最高等级​↓​OrderUI每0.5秒检查 → 棋盘物品够了就亮起\"交付\"按钮​↓​玩家点\"交付\" → 从棋盘扣除物品 → 发金币/经验 → 标记完成 → 解锁后续订单 → 刷新列表​关键设计:订单解锁是链式的(UnlockOrderId),保证玩家按设计好的顺序推进内容。难度上限(最高等级+2)防止出现玩家根本做不到的订单。​待完善的功能:​1.订单的横向滑动和显示逻辑:目的是让游戏后期要显示多订单时,控制同时显示的数量,避免玩家目标混乱。​2" + }, + { + "group": "创新组", + "sender": "徐锐", + "time": "2026-05-22 19:22:14", + "url": "https://dianchukeji.feishu.cn/wiki/RIhawaIYwiBGHak7YAVcaSapnTe", + "content": "日报 徐锐输入“/”快速插入内容2026-05-22-日报 徐锐​用户2199用户21995月22日修改1. 工作内容概述​1.基础功能线——UI美术资源系统搭建——完成了UI美术资源管理系统的代码实现,建立自动化纹理加载框架​2.美术线——UI美术资源汇总表整理——输出了完整的UI美术资源需求清单(39项),按P0/P1/P2分级​3.探索新的AI工具——调研并测试了多款AI辅助开发工具,包括会议上其他同学提到的新的工作流等​4.美术AI生成探索——尝试使用AI工具生成游戏美术素材​2. 成果​2.1 基础功能线——UI美术资源管理系统搭建​背景:原有UI界面全部使用纯色 ColorRect + 文字占位,没有贴图资源管理机制,美术交付后需要大量手动改造。​实现方案:​模块​内容​UI资源汇总表​在《冰雪餐厅_美术资源汇总.xlsx》中新增\"UI美术资源\"Sheet,列出39项UI贴图需求,分为通用控件(common)、战斗界面(battle)、任务系统(task)、玩家信息(player)四大类,按P0/P1/P2优先级标注​UIAssets AutoLoad​创建scripts/ui_assets.gd全局单例,集中管理所有UI贴图路径常量,提供load_tex()自动加载 +try_set_tex()兜底降级机制——贴图存在时用贴图,不存在时自动回退到纯色/文字​引擎改造​修改main.gd(主界面背景/Logo/头像/资源图标/按钮三态)、battle.gd(棋盘底板/格子槽位/遮罩层/订单卡片)、task_system.gd(任务面板/进度条)、player_info_popup.gd(玩家弹窗/经验条)全部接入 UIAssets 系统​好处:美术只需将PNG放入对应目录,游戏即可自动加载,无需修改代码。​以下是临时生成的美术资源接入的表现效果​2.2 美术线——UI美术资源汇总表整理​输出了完整的39项UI贴图需求清单:​-通用控件 (common/):背景、Logo、头像框、体力/金币/钻石图标、按钮三态(普通/悬停/按下)、等级徽章、弹窗背景等​-战斗界面 (battle/):棋盘底板、格子槽位、隐藏/半透明遮罩、订单卡片、完成按钮、仓库面板​-任务系统 (task/):任务面板背景、进度节点(已完成/当前/待完成)、开始按钮​-玩家信息 (pla" + }, + { + "group": "创新组", + "sender": "徐锐", + "time": "2026-05-22 11:00:22", + "url": "https://dianchukeji.feishu.cn/wiki/SmxzwvhHOi0rk1kSXxmcMobGnGd", + "content": "" + }, + { + "group": "创新组", + "sender": "刘鹏", + "time": "2026-05-22 10:59:53", + "url": "https://dianchukeji.feishu.cn/wiki/MObLwsaWoirykyke8NXcFUlhnfd", + "content": "工作进度总结-刘鹏输入“/”快速插入内容2026.05.22工作进度总结-刘鹏​用户2416用户24165月22日修改当前阶段完成的工作内容​后续工作计划​表格​​" + }, + { + "group": "创新组", + "sender": "韦译", + "time": "2026-05-22 10:57:59", + "url": "https://dianchukeji.feishu.cn/wiki/YniYwtxAiiKqcmkmVM5clNxTnQf", + "content": "工作流文档输入“/”快速插入内容工作流文档​用户6299用户62995月22日修改​" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-22 00:21:29", + "url": "https://dianchukeji.feishu.cn/wiki/ZVOVw5BCriBcUfkT1cFcOw3nnBc", + "content": "日报-王雨默输入“/”快速插入内容2026.5.21-日报-王雨默​用户2965用户29655月22日修改一.工作内容概述​•使用生图工作流来产出美术资产,解决过程中遇到的问题​•完成主菜单美术资产产出,并在游戏内进行替换​•小功能点优化:补充关卡模式前期自动揭示逻辑、增加金币显示UI​•整理汇报内容​​二.生图工作流测试验证情况​今日主界面资源出图过程中暴露出多个问题,主要集中在复杂需求理解、图片尺寸控制和后处理质量上。​1.Agent Team 全自动流程仍无法应对复杂需求​原计划是通过 Agent Team 完成从需求分析、资源生成、拆分、后处理到入库的完整自动化流程。但实际执行中发现,当前流程在中间脚本调用、状态传递、工具接口使用等环节频繁出错。​比较明显的问题是:流程还没有真正进入高质量出图阶段,前置的脚本调用和任务编排就已经产生较多异常。这说明当前 Agent Team 流程的稳定性不足,如果继续强行推进全自动化,反而会放大试错成本。​因此今日将主流程调整为半自动逐模块流程,即:按模块拆分需求 → 单模块生成 → 人工确认 → 修正问题 → 后处理 → 入库​这种方式虽然自动化程度较低,但可控性更高。尤其是在复杂 UI 资源还无法稳定一次生成到位的阶段,逐模块处理能更快定位问题,也能减少整套资源返工的成本。待这套流程经多次测试,沉淀出稳定可复用的规范时,再考虑往全自动化方向发展。​​2.复杂 UI 界面 prompt 问题​对于元素数量较多、层级较复杂的主界面 UI,之前测试过程中使用的简单描述已经很难让 image2 准确理解需求。模型在处理复杂界面时,容易自行补充、重绘或改变元素结构,导致输出结果虽然风格接近,但具体布局、元素比例和资源样式与预期存在偏差。​在今日实际测试中,已经尝试让 agent 先对主界面进行结构分析:一方面输出需要拆分的 asset sheet 清单,另一方面同步给出各个元素的位置、尺寸信息。随后再将这些结构化信息提供给 image2 作为生成约束。​从测试结果来看,这种方式下,模型对整体界面结构的理解更稳定,生成出的资源在比例、布局关系和样式一致性上都有提升,能够更好地减少模型自由发挥带来的偏差。​这次尝试说明,复杂 UI 出图的关键并不只是加强风格描述,而是要让模型获得更明确的空间结构约束。后续可以将该方式沉淀为固定流程:先" + }, + { + "group": "创新组", + "sender": "韦译", + "time": "2026-05-21 23:13:47", + "url": "https://dianchukeji.feishu.cn/wiki/AjK2wPpI7iOFo5kOImVcEe1WnNS", + "content": "工作内容概述​1.调研接入抖音/微信平台的方案​2.基础功能线——对已有系统的优化——优化棋盘和订单系统的一些bug​3.W2线——广告接入—— 用Mock模式跑通广告位的全流程(预计明日进入微信开发者工具进行测试)​4.完成了整个项目配置方案的设计和实现,其中的重点是物品链schema的设计与实现。能够帮助后续使用AI批量生成关卡、关卡数值​5.基本程序策划工作流文档的编写,还差一点收尾(预计明日早上完成2个工作流文档的编写)​2.进度​2.1 调研接入抖音/微信平台的方案​综合二合项目本身的特点和各个平台的优缺点,调研了几个方案,最终选择综合的方案C:先上线微信验证技术,然后针对抖音玩家和算法偏好进行新一轮的美术包装和视觉反馈设计,再上抖音​​关于项目选择抖音平台还是微信平台接入的调研选择​2.2 基础功能线——对已有系统的优化——优化棋盘和订单系统的一些bug​问题​修法​订单最多只能承接5单,这5单还都是随机生成的,没有固定订单系统的数值设计​​新增 configs-src/orders/main_20.yaml 和对应 schema,通过这些配置,能够规范设计最多20单的订单数值:例如物品种类、物品数量​以前做完一批订单后,游戏容易没东西可做​出完再自动补下一批”,这样主棋盘不会断。​以前每单奖励都是固定的数值​现在每一单都能单独配金币奖励,前面简单一点,后面奖励和难度一起往上走。​以前生成器解锁是静态的​现在改成了“攒够金币、推进到剧情节点后,逐步解锁新生成器”,比如先开面包,再慢慢开饮料、甜点。​以前存档可能会把进度弄丢​现在把“做到第几单”和“已经解锁了哪些生成器”都存起来,退出再进不会回退。​以前按钮点了和实际状态可能对不上​​现在“新增”按钮会先判断有没有可解锁的生成器,再去生成物品,避免玩家点了没反应或者逻辑错乱。​2.3 W2线——广告接入—— 用Mock模式跑通广告位的全流程​目前能够完整跑通广告位的流程,后续只需要在微信开发者工具上,把当前模拟的假的广告,换成真实的广告API即可​2.4 完成整个项目配置方案的设计和实现​◦整个配置方案的设计:​​设计规则层:JSON Schema + Agent 生成配置内容时约束​↓ 约束​源配置层:YAML 配置表​↓ 构建脚本转换、校验、合并​运行时层:JSON 配置表​↓ Cocos 加载​游戏" + }, + { + "group": "创新组", + "sender": "刘鹏", + "time": "2026-05-21 22:35:51", + "url": "https://dianchukeji.feishu.cn/wiki/F05nwzkQ0ioUxRkNaV8cEBvzn6b", + "content": "日报-刘鹏输入“/”快速插入内容2026.05.21日报-刘鹏​用户2416用户24165月22日修改一、工作概述​1.完成前两天的方法论和提示词梳理沉淀​2.进行棋盘模块、生成器模块和合并模块的功能开发​3.尝试icon的批量生成和UI的成套生成​二、主要产出​2.1-前两天工作过程中的提示词和方法论的沉淀梳理:​对前两天前期验证和调研过程中产出的方法论和提示词进行梳理​主要包含模块:方向调研、策划案生成、Schema生成、美术icon和UI生成​文档链接:​AI提示词和方法论沉淀​2.2-棋盘模块、生成器模块和合并模块的功能开发:​2.2.1配置数据层与数据加载​目前尝试AI配置的提示词偏向硬性指标向的,如生成器生成范围为1~2级,遮挡的物品数量占比要超过50%等,目标是快速获得一个贴近主流产品如四季合合的功能表现,明天会尝试在此基地上,通过目标/体验指向来看AI是否能根据体验区配置参数,同时还会设置一个对照组,例如一开始就让AI以体验为目标直接配置的参数,检测保底标准对最终效果的可能影响​运行后加载配置​2.2.2棋盘模块 (BoardController)​棋盘初始化:​•根据BoardData.InitGridNum(49)计算7×7网格尺寸​•动态生成GridCell对象,自动设置正交世界坐标(居中排列)​•无Prefab时运行时生成白色方块Sprite + BoxCollider2D​初始布局填充 (PopulateInitialLayout):​•读取BoardLayout.json的49条配置​•三种覆盖状态处理:​◦none→ 直接SpawnItemAt​◦half_cover→ 设置半遮挡状态 + ForceSpawnItemAt(物品可见但不可拖动)​◦full_cover→ 设置全遮挡状态 + ForceSpawnItemAt(物品不可见不可交互)​生成器放置 (SpawnGenerators):​•以曼哈顿距离从棋盘中心向外寻找空格​•优先将生成器放置在最靠近中心的可用格子​" + }, + { + "group": "创新组", + "sender": "徐锐", + "time": "2026-05-21 21:57:45", + "url": "https://dianchukeji.feishu.cn/wiki/Qad6w4jY9iweK5kggeCcLkifnIN", + "content": "日报 徐锐输入“/”快速插入内容2026-05-21-日报 徐锐​用户2199用户21995月22日修改工作内容概述​1.项目系统完善与搭建:完成了游戏的基础循环,但在构建对话和建筑等级系统时遭遇了较大bug,只能先进行回退,后续再慢慢尝试。同时还初步导入了几个临时的图片素材进行测试,可以正常加载图片素材。​a.解决方法:后续将进一步拆分并细化对话系统与建筑等级系统的规则,将复杂功能拆解为多个独立模块,逐步描述并交由 AI 分阶段实现,以降低逻辑冲突与 Bug 出现概率。​2.游戏主题确定与素材生成尝试:初步决定使用冰雪餐厅作为主题,生成了一些图片,但一致性较差,让AI生成了一版提示语,后续再尝试生成​a.选择冰雪餐厅为主题的原因:一方面,《Whiteout Survival》等冰雪题材产品在海外市场热度较高,说明冰雪风格在用户审美与题材接受度上具备一定优势;另一方面,目前市面上的餐厅经营类游戏较少采用冰雪主题,因此希望通过“冰雪+餐厅经营”的结合做出一定差异化,在视觉氛围与题材方向上形成独特记忆点。​b.AI图片素材解决方法:后续将统一角色、场景、光影与配色等关键词描述,固定美术风格与视角设定,减少 AI 生成时的随机偏差;同时优先采用“同一套提示词迭代修改”的方式生成素材,以提高整体素材的一致性。​3.浪漫餐厅初始物品调研:调研了浪漫餐厅的棋盘初始物品并应用在了游戏中。​成果​1.项目开发进度​2.素材清单:​冰雪餐厅_二合游戏素材清单.md、​3.物品调研:​​4.​开发计划​心得体会​在本次项目开发过程中,我逐渐意识到,使用 AI 进行程序开发时,前期的需求拆分与规则描述比直接生成代码更加重要。尤其是在对话系统与建筑等级系统的开发中,由于一开始规则描述不够细致,导致 AI 对部分逻辑理解出现偏差,从而产生了较多 Bug。后续通过先让 AI 分析提示词中可能存在的边界问题、逻辑冲突以及理解不明确的部分,再逐步补充规则后,程序生成的稳定性明显提高,返工成本也有所降低。​同时,我也进一步体会到“模块化拆分”的重要性。相比一次性生成完整系统,将各个功能拆分为多个独立模块、逐步实现与测试,更容易定位问题并保证整体功能的正常运行。这种方式不仅降低了复杂系统开发时的混乱程度,也让后续修改和扩展更加方便。​在美术素材生成方面,我认识到 AI 生成图片虽然效率较高,但如果缺少" + }, + { + "group": "创新组", + "sender": "韦译", + "time": "2026-05-21 01:13:40", + "url": "https://dianchukeji.feishu.cn/wiki/JY56wsBHniMVP6k7y7scQ4gUnOg", + "content": "日报-韦译输入“/”快速插入内容260520日报-韦译​用户6299用户62995月21日修改1.工作内容概述​1.基础功能线——完成订单系统,包括2个小功能:订单交付按钮、对应物品的格子高亮​2.基础功能线——金币和钻石经济货币接入:配合订单系统需要,进行真实接入,不再使用假数据​3.W2线——广告接入​a.完成对广告接入的调研工作​b.目前正在用假数据尝试跑通触发广告的整个流程,预计明日能够跑通​4.美术线——UI优化:调整美化了订单系统的UI;对几个重要的按钮添加了icon图标​2.进度​2.1 基础功能线——完成订单系统​◦订单交付按钮:如果棋盘上凑够了订单所需物品,则此时在订单上显示完成按钮,玩家点击按钮后进行订单交付​◦对应物品的格子高亮:如果棋盘上的物品是订单所需的物品,则该物品的格子高亮,用于提示玩家​2.2 基础功能线——金币和钻石经济货币接入​◦接入真实金币和钻石数据,目前暂定经济货币绑定玩家的本地存档​◦每完成一件订单增加一定数量的金币,目前暂定每完成一件增加10货币​◦钻石目前还没做相关设计。开发成真实数据主要是为了购买额外奖励。​2.3 W2线——广告接入​◦调研:用多个AI工具,对cocos项目接入商业化广告项目进行了调研,得出几个方案​▪方案:​•A. 微信开发者工具模拟+工具内置广告模拟弹窗 (创建→show→onClose→发奖)​•B. 真机调试 + 测试广告位+微信官方提供测试adUnitId,能够跑通完整链路和真实广告样式​•C. Mock模式(自己封装假数据) 代码层模拟广告回调逻辑链路​▪结论:​•阶段1(现在)→ 方案C:Mock 模式跑通全流程​•阶段2(有AppID)→ 方案A:开发者工具模拟 +​•阶段3)(打包上线版本后)→ 方案B:真机调试 + 测试广告位​•阶段4(用户量足够后)→ 开通流量主 → 填入真实 adUnitId → 真机验证真实广告​▪主要卡点:​•真实广告API接入的门槛高:微信要求有1000个用户后才能开通流量主,获得adUnitId,才能接入真实的广告的API​•新的开发环境:上微信抖音平台需要接入微信/抖音开发者工具,这是另外一套没接触过的开发工具,需要探索学习​◦目前的进展​▪处于阶段1:目前尝试用Mock模式跑通广告位的全流程,今天已经完成接入广告前的流程,具体如下​•玩家二合后,有" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-21 01:06:56", + "url": "https://dianchukeji.feishu.cn/wiki/FMV0w4C8ai0oJXkxzhFcygeqnQB", + "content": "日报-王雨默输入“/”快速插入内容2026.5.20-日报-王雨默​用户2965用户29655月21日修改一.工作内容概述​•搭建美术Agent Team,跑通多agent协作资产交付流程​•重新确认项目美术风格方向​​二.美术Agent Team搭建​当前项目在 UI 生图和资源交付过程中,已经不只是单纯生成效果图,而是逐步进入到“正式资产生产”的阶段。因此需要建立一套更稳定的多 Agent 协作流程,用来解决以下问题:​•正式资产交付​◦不只生成概念图或临时效果图,而是要能够输出可入库、可复用、可接入 Cocos 项目的资源文件。​◦资源需要经过切片、透明背景处理、命名规范、QC 检查等步骤,避免后续人工返工。​•控制美术风格统一性​◦之前单次生图容易出现风格漂移、细节不稳定、不同批次资源不一致的问题。​◦因此需要引入 art-director 角色,专门负责方向把控、概念审核和最终风格验收。​•支持后续功能拓展​◦除了生成图片资源,还需要配套完成资产管理、库存更新、配置文件生成等工作。​◦后续如果继续推进自动拼 UI Agent,也需要提前沉淀 layout JSON、资源清单、命名规范等结构化数据。​因此,这次搭建的目标不是单个生图脚本,而是面向正式生产的美术资源生成协作流程。​1.实现思路​本次将美术生产流程拆分为三个 Agent 角色,由主 session 进行统一调度和确认。​art-director:负责美术方向和风格验收​art-director 的定位是主美 / 美术总监,主要负责:​•根据项目已有的art_direction.md、style_anchors.md等文档分析美术方向;​•判断新需求是否符合当前项目视觉定位;​•审核 asset-artist 生成的 concept 图;​•检查 sheet 和最终资源是否存在风格偏移;​•根据asset_inventory.md判断是否已有资源可以复用。​这里特意限制 art-director没有最终决策权。它只负责提出审核意见,所有结果都需要汇报给主 session,再由主 session 展示给用户确认,避免 Agent 自行推进导致方向失控。​​asset-artist:负责资源生成、图集生成、切片和 QC​asset-artist 是实际执行生图和资源处理的角色,主要负责:​•根据 ar" + }, + { + "group": "创新组", + "sender": "刘鹏", + "time": "2026-05-20 21:45:20", + "url": "https://dianchukeji.feishu.cn/wiki/IM5zwpPKUixJBUkninjccrl0njg", + "content": "日报-刘鹏输入“/”快速插入内容2026.05.20日报-刘鹏​用户2416用户24165月22日修改一、工作概述:​1.AI绘制游戏内物品图片和UI的工具链验证​2.落地实施方案的具体规划确定​3.Schema生成标准化、细化。​二、AI美术的工具链验证:​1.基础物品icon绘制:豆包AI绘制透明背景的多格icon整图——>Image Splitter进行分块切割​优点:工具无额外使用成本,出图快,风格可控(采用同一风格的参考图生成,风格的可控率在90%,细节上会有一点小变动)​可提升点:出图结果的有效性目前比较随机,保底70%,主要受物品的知名度和特征明显程度、参考图的质量以及提示词的描述细致程度影响。提升的方向为物品选择时尽量选有明显特征和高知名度的物品。提示词尽可能详细的描述物体(可以使用AI生成对应物品的提示词描述),若对物品准确性要求不高可适当粗略的描述物体来进行抽卡操作,逐步提取合适的物品。参考图也尽可能选取清晰风格统一的图片(例如对标产品的界面高清图)​豆包AI绘画提示词:​结合参考的风格生成一套以下物品icon整图:​玉石矿屑​原生玉原石​雕花玉簪​平安扣玉佩​和田玉扳指​和田玉手链​冰种玉佛吊坠​冰种玉宽镯​青玉文房镇纸​瑞兽玉雕​帝王绿玉牌​满绿翡翠手镯​祥瑞玉如意​每个物品占据一个方形网格,每个网格大小相同。网格间用白线隔开,透明背景。​风格参考​32%产出结果​32%​图像分割​37%2.UI风格绘制工具(探索中):Game UI,可以基于草图和文字描述生成某一品类的完整界面图片,并可直接提取出图片中的UI元素。​优点:风格统一,整套UI/界面出图快,界面元素完整度高​缺点:生图有成本,单次生图+拆分的价格为1.4元。无法直接对单个UI元素进行更改,只能进行整体界面的调整。后续持续探索与其他工具融合实现UI快速批量生产。​三、具体落地方案:​包装方案的确定流程为​画板项目主题:现代珠宝首饰​世界观概述:(天才设计师逆袭翻盘 + 手撕小人复仇爽感 + 女性独立搞事业崛起)​天才珠宝设计师曾凭借原创穿搭首饰风靡都市,却惨遭同行闺蜜背刺 —— 设计手稿被窃取、苦心经营的网红珠宝事务所被霸占、客源与物料尽失,最终落魄离场。沉寂后,她接手一间濒临倒闭的小众珠宝事务所,决心重振旗鼓,以两两合并原石、金银、水晶等基础物料制作各类日常穿搭首饰为起点,承接" + }, + { + "group": "创新组", + "sender": "徐锐", + "time": "2026-05-20 19:41:35", + "url": "https://dianchukeji.feishu.cn/wiki/AqzvwhCH9iKYfbkQ5iacMuKJnMe", + "content": "日报 徐锐输入“/”快速插入内容2026-05-20-日报 徐锐​用户2199用户21995月20日修改1.工作内容概述​1.美术AI工具调研与尝试:尝试了2D游戏素材生成,包括Holopix、Banana、SD等,生成了一批临时素材。​2.产品设计文档深化与临时配表:​◦检查并完善了昨日设计文档的初始框架。​◦针对二合(Merge)玩法的核心数值逻辑(如生成器产出概率、物品升级链条、体力消耗与产出平衡),设计并制作了第一版临时数据配表(Excel/CSV),便于后续框架开发​3.其他AI辅助工具横向尝试:​◦拓展尝试了除CodeBuddy之外的其他AI编程/全栈辅助工具(如Cursor、Claud等),在网络环境上遇到了一些问题,有些模型时需要外网环境才能使用,比如接入Codex的API后显示网络有问题,明天找程序帮忙解决。​成果​•美术临时资源:生成了一批临时Icon和UI素材,便于后续开发​•临时数值配表 v1.0:确立了基础物品合成树及产出概率表,为下一步原型注入动态数据做好了准备。​item.xlsx心得体会​•AI 辅助开发的广度与深度感知:在今天对 Cursor以及各类美术 AI 工具的调研中,我深刻感受到了当前 AI 工具的智能与强大。它们不仅能高效输出美术临时资产,在代码辅助和逻辑构架上展现出的理解力也十分强大。虽然目前在网络环境配置上遇到了一点小插曲,但这些工具在提高生产力、加速原型验证方面的巨大潜力毋庸置疑。在接下来的开发中,我会进一步挖掘并整合这些 AI 工具的优势,为项目提效。​明日计划​1.数据配表接入引擎:尝试将今天的临时数据配表导入正式开发环境中​2.美术资产替换:尝试将将今天生成的AI临时美术资产替换进游戏场景中,告别“白块”开发。​3.AI工具正式开发:其他AI工具的开发使用​​" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-20 04:22:08", + "url": "https://dianchukeji.feishu.cn/wiki/XRMpwLyT6i55YykYcZScuyRWnyh", + "content": "日报-王雨默输入“/”快速插入内容2026.5.19-日报-王雨默​用户2965用户29655月20日修改一.工作内容概述​•修复碎片收集界面在真机测试过程中出现的“碎片显示异常”、“动画表现异常”问题。​•确认项目美术概念方向,尝试建立规范,在后续工作流中最大限度保证美术资产的风格一致性,​•Responses API 生图链路验证,UI 生图工作流方案收敛​​二.美术概念方向确定​1.抖音小游戏主流品类与美术风格分析​主玩法品类​代表方向 / 产品​常见美术倾向​核心优势​对项目的参考价值​IAA休闲 / 超休闲​抓大鹅、羊了个羊、拧螺丝、挪车、倒水排序、机关消除类小游戏​明快卡通;图标大而清晰;操作区域突出;道具入口明显;成功、失败、奖励反馈强​用户能快速理解玩法,适合短局体验、广告变现和短视频传播​可以借鉴其短局节奏、提示广告、通关反馈和分享挑战设计,但不能只做成安静的逻辑题界面​二合模拟经营​浪漫餐厅、四季合合、梦幻旅行、家园修复、餐厅经营、百货店经营​温暖治愈;生活化场景;低饱和暖色;角色亲和;UI 圆润;装修、收集、任务反馈较强​长期目标感和留存能力较强,能通过建设、收集、剧情推进维持用户动力​项目本身不是经营玩法,但可以借鉴其长期目标设计​塔防 / 射击 / 割草​向僵尸开炮、猎梦保卫战、生存类小游戏、末日防守类小游戏、割草 like 产品​高对比;战斗感强;怪物密度高;伤害数字和攻击特效明显;短视频素材表现力强​战斗爽感强,成长反馈明确,素材容易剪出刺激点​整体风格不适合项目,但可以借鉴其“强反馈意识”​中重度成长类​放置 RPG、SLG、卡牌、传奇、仙侠、末日生存等​角色立绘、装备、数值成长、基地/阵容/技能表现较重,视觉层级更复杂​付费深度和长期成长空间更强​项目不适合直接参考其美术体量,但可以少量借鉴成就、章节、收集和成长反馈,不应引入过重数值感​2.最终方向确定​基于前面对抖音小游戏主流品类和美术风格的分析,当前项目最终美术包装方向确定为:小鸡侦探社​该方向的核心并不是单纯将动物形象从“牛”替换为“小鸡”,而是围绕项目本身的逻辑推理玩法,建立一套更容易被用户理解、也更方便后续美术资产持续扩展的主题包装。​项目本质上属于轻益智逻辑解谜玩法,玩家需要根据颜色区域、行列限制、相邻限制等规则,逐步排除错误位置并找出目标。因此,美术包装需要同时满足两" + }, + { + "group": "创新组", + "sender": "卓泽", + "time": "2026-05-20 01:28:09", + "url": "https://dianchukeji.feishu.cn/wiki/ZdTPwDH8NiSh09kOuHicQvLSnZd", + "content": "日报-卓泽输入“/”快速插入内容20260519-日报-卓泽​用户4681用户46815月20日修改一.今日工作内容概述​•继续推进新游戏内容接入,围绕武器、敌人、宝箱、美术特效和相关配置做了完整整合。​•同步补充了部分游戏数值相关工作,尝试调整一套提示词让Agent进行数值体系设计,并围绕基础成长、配置映射和数值表现联动做整理与调整。​•继续处理粒子特效与战斗表现相关内容,让命中、爆破、受击、开箱等关键反馈在视觉层面更完整、更统一,也让战斗过程中的反馈层次更清晰。​​二.新游戏内容接入推进​1.武器、敌人、宝箱与特效资源整合​•今天的重点仍然是把新游戏内容从“有资源”推进到“可接入、可配置、可验证”的状态。​•在武器资源方面,继续完善了资源导入、配置映射和表现接入,让武器不只是静态素材,而是能够被系统正确识别和使用。​•在敌人资源方面,补充了敌人测试资产和相关配置,便于后续快速验证敌人表现、战斗交互和阶段流程。​•在宝箱资源方面,补齐了宝箱相关美术资源和开箱特效,使奖励展示和战斗反馈链路更完整。​•在美术特效方面,继续接入战斗中常用的命中特效、爆破特效、耗尽特效等内容,增强整体表现一致性。​界面后续继续进行打磨, 资产题材也依据后续反馈来调整​三.游戏数值与Agent数值配置​1.数值体系设计尝试​•今天同步补充了部分游戏数值相关工作,重点不是单纯改数值,而是尝试让Agent参与数值体系设计。​•在这个过程中,先调整了一套提示词,希望让Agent能够围绕游戏的基础成长、阶段节奏、资源投入产出以及配置结构来做更系统的整理。​•这样做的目的,是减少完全手工梳理数值时的重复成本,把一部分规则整理、框架归纳和基础方案设计交给Agent先做初稿,再由人工判断是否符合当前项目方向。​•这类尝试更偏向于方法层面的验证,重点是观察Agent在数值体系这种“规则明确但需要整体感”的任务上,能不能稳定给出可用结果。​使用提示词如下​你是游戏数值策划, 看看项目文档文件夹, 理解这是什么项目, 现在项目的数值还完全没有设计​先整理数值的配置方法, 输出一个文档到\"\\设计文档\", 然后告诉我你对于下面的任务的计划:​项目的数值设计目标: 玩家可以在不停看广告的情况下获得指数增长(也就是不停获得最高等级-0~n的武器), 否则增长来自武器生成器与修仙等级增长的次方增长​要设计敌人的难度曲线" + }, + { + "group": "创新组", + "sender": "韦译", + "time": "2026-05-19 20:41:01", + "url": "https://dianchukeji.feishu.cn/wiki/KGMJwIMWOiMnnVk2wyrc0OaRnkh", + "content": "日报-韦译输入“/”快速插入内容260519日报-韦译​用户6299用户62995月20日修改1.工作内容概述​1.研读三份报告,调整自己的开发计划​2.把目前的小型闯关制度,改成类《浪漫餐厅》的大型关卡长时间推进机制​3.游戏内ui继续改进:接入订单区域背景图、餐桌、餐盘,实现订单区域的拖拽,但有仍有不少问题​4.目前游戏的性能差,有很多卡顿,需要优化(发现web网页端不卡,只有编辑器卡,经过跟AI讨论,目前以真机的体验为准,编辑器只做参考)​5.开始开发无限订单机制,预计明日完成​2.进度​2.1 研读三份报告,调整自己的开发计划​◦之前的开发计划主要围绕开发本身,没有重点考虑资产沉淀、接入商业化功能相关的部分。三个报告文档指出了需要沉淀的具体资产、商业化功能,明确了往后的开发方向。目前已经完成了W1的绝大部分内容,本周剩余时间将重点开发W2中的内容。​◦以后的日报将持续跟踪三份报告中给出的开发计划。在第五节项目规划中更新每日进展。​2.2 把目前的小型闯关制度,改成类《浪漫餐厅》的大型关卡长时间推进机制​◦承接昨天的机制分析,今天开始开发此机制,并完成开发。​▪具体效果:在主界面和游戏场景切换时,会保留游戏进度​2.4 游戏内ui继续改进:接入订单区域背景图、餐桌、餐盘,实现订单区域的拖拽,但有仍有不少问题​◦昨天已经生成好美术资源,今天进行接入,勉强达到了浪漫餐厅的大致效果。但还有很多小问题。​▪效果如下:​•订单区域背景图、人物立绘、餐盘已经成功接入​•订单可以左右拖拽​​◦遇到的问题如下​▪UI细微调整问题:对于餐桌、人物立绘、餐盘的组合摆放,属于ui的细微调整。目前的AI还难以解决这一块的内容,所以我进行了手动调整。但是AI给我的方案是,让我在代码里面调整。每调整一次都要经过编译再运行,每次都浪费了不少时间。经过跟义烽和雨默的讨论后,我才发现是inspector问题。​•inspector问题:我没有把这些需要频繁配置的ui数值接入inspector中。正常都是要接入的,这样就可以实时预览来调整方案。​•反思:之前在godot上使用AI时,AI都会自己帮我配置好inspector,但是我在cocos的使用过程中没有注意这一点,浪费了很多时间。后面要加强对于inspector的使用,把这些需要频繁配置的内容接入inspector,能够实时配置调整ui。​" + }, + { + "group": "创新组", + "sender": "刘鹏", + "time": "2026-05-19 20:38:21", + "url": "https://dianchukeji.feishu.cn/wiki/DTPlwRI46iKAgfkKvozcBHF1n7c", + "content": "日报-刘鹏输入“/”快速插入内容2026.05.19日报-刘鹏​用户2416用户24165月20日修改一、工作内容概述​1.对二合类微信端头部产品浪漫餐厅、四季物语、四季合合进行了前期体验调研​2.使用IMA完成宝石主题二合类游戏物品链Schema(JSON格式)​3.配置UnityMCP环境,验证程序工具链生成效果​二、前期调研产出​通过多AI数据收集+人工审核数据准确性的方式,收集当前市场的基础数据​(市场基础情况调研数据)​结论:目前二合市场的主要目标用户为女性轻度休闲用户,且多为年轻女性,用户追求治愈的情感感受和短频快的体验反馈。田园/家居是微信小游戏端最大的流量池,占比高达50%。此类主题更贴近“装修”、“装扮”等泛女性向社交需求,符合“泛用户共鸣”原则,第二大的餐饮美食类的表现也比较稳定,恋爱和IP授权是差异化切入点,但市场验证的产品较少,具有较大的用户改造风险,但同样也适合当前做快速市场验证的阶段目标,因此我觉得可以考虑未验证但存在可能性的潜力主题。​(玩法结构基础调研数据)​结论:核心循环结构:核心合成→【订单】→【装修/剧情/剧本】→【获得新生成器/奖励】→【更高阶订单】​最终决策:​合成主题:选择为珠宝首饰方向(避开目前市场美食等存量竞争激烈的主题),符合年轻女性的泛用户定位;​目标驱动:以订单驱动为短期主要目标,辅助添加长线珠宝首饰图鉴为长线收集目标​三、物品链Schema​将要求文档导入IMA,确保AI参考资源的有效性,输入以下提示词,生成测试物品链Schema:​请为我的二合类游戏生成一个物品链Schema(JSON格式),要求:​•主题:[宝石]​•合成链长度:12-20级​•字段定义包含:等级(level)、物品名(name)、图标ID(icon_id)、合成规则(merge_rule)​•示例:Level 1 → Level 2 → ... → Level 20​•输出格式:JSON Schema​​目前生成的主要为测试用例,明天会尝试优化生成结构和提示词​四、程序工具链生成效果​使用IMA结合文档要求生成规范的需求提示词,人工修改后发送给claude,直接生成可运行的原型​" + }, + { + "group": "创新组", + "sender": "徐锐", + "time": "2026-05-19 20:12:20", + "url": "https://dianchukeji.feishu.cn/wiki/OY6KwrH1Rifryrk80nSc4aRPnig", + "content": "日报 徐锐输入“/”快速插入内容2026-05-19-日报 徐锐​用户2199用户21995月20日修改1.工作内容概述​1.AI代码平台搭建:暂定使用CodeBuddy(代码生成工具)+Godot(游戏引擎)+deepseek个人模型​a.选择原因1:Codybuddy与微信小程序生态的工具链兼容性相对较好。​b.选择原因2:godot使用的是codebuddy的定制化版本,使用起来相对方便,另外应该也会有一些专门优化。​c.选择原因3:Godot里的核心场景文件.tscn和核心资源文件.tres,本质上是TOML语法的变体实现。TOML有极强的声明式特征,并且对人类和AI都拥有可读性。AI使用时可以不通过MCP,只通过grep文档的形式直接修改.tscn文件,相比其他软件必须使用MCP辅助更加方便。​d.选择原因4:Deepseek是相对性价比最高的模型,所以想试着先使用,如果后续明确出现了十分困难的阻碍会立即进行替换。​e.选择原因5:个人觉得智能度相对不那么高的引擎能够在一定程度上监督项目具有一个清晰的架构,如果是一个架构十分清晰的项目,这套组合也应该可以实现最终成品。​2.二合类游戏玩法原型制作​3.merge类产品关卡指标拆解草稿​浪漫餐厅关卡指标拆解​4.merge类产品设计文档初步制作​2.成果​a.产品初步原型​b.游戏设计文档​​mergeAI产品设计文档​3.心得收获​a.AI平台搭建:通过对各类资料的收集掌握了codebuddy生产工具的搭建与使用,以及API的配置、以及Codebuddy与Godot的链接,可以更加方便地进行游戏开发​b.AI辅助设计:先口述部分核心逻辑规则,让AI进行完善和梳理,可以加快工作效率,也能在生成原型时让AI更容易理解​4.明日计划​a.美术AI工具调查与学习使用尝试​b.产品设计文档继续完善​c.figma原型图转代码尝试​" + }, + { + "group": "创新组", + "sender": "卓泽", + "time": "2026-05-19 02:10:37", + "url": "https://dianchukeji.feishu.cn/wiki/WiBfwLPy1iBhk5kHfQPccx2un0f", + "content": "日报-卓泽输入“/”快速插入内容20260518-日报-卓泽​用户4681用户46815月19日修改​一.今日工作内容概述​•尝试引导Agent跑通美术资产从生成到配置的完整工作流程,整体效果不错,说明这类“重复度高、链路长、规则明确”的任务适合引入 Agent 参与​•继续推进游戏开发工作,主要包括:​◦完成 UI 配置器开发,补齐了当前项目 UI 资源配置和组织的一部分编辑能力。​◦修复了一批现有 Bug,提升了当前版本的稳定性。​◦梳理目前项目中 Unity UI 实现与配置对 AI 开发的优劣,为后续继续用 AI 介入 UI 配置、资源整理和批量数据处理提供参考。​二.关于 Agent 执行美术资产配置​1.背景与目标​•AI 程序已经系统性给出交接文档,按正常流程原本需要由人类逐一完成资产生成与配置。​•但这批资产重复度高、批量大、流程固定,适合让 Agent 介入,把重复劳动交给自动化处理。​•本次尝试的目标不是单次追求最大产量,而是先跑通“生成 -> 处理 -> 落盘 -> 导入 -> 配置 -> 验证”的闭环,确认后续能否稳定扩展。​•交接信息中已经覆盖了总述、敌人资产配置方法、特效资产配置方法和常见问题,其中总述部分还包含放置目录、导入设置建议、引擎内操作流程和等级循环规则,整体足够支撑 Agent 上手。​2.交接资料与资源准备​•项目认识部分:​◦项目文档:作为直接相关的主参考文档。​◦项目路径:将代码结构作为文档补充,便于 Agent 同时对照资源位置和配置入口。​◦由程序AI撰写的​资产配置说明​•资产生成部分:​◦API key(已脱敏):供 AI 工具调用 MeowArt。​◦API key 文档:用于让 Agent 理解鉴权格式、参数传递和调用约束。​•平台说明:​◦MeowArt 是一个面向批量生成风格化资产、并提供 API key 的平台。​•额外尝试:​◦新建子 Agent,并设置好工作路径,让其直接引用交接文档和项目资源执行任务。​◦同步尝试接入 meowa-skills 中的 game-assets 能力,目标是把资产生成、导入和配置串成标准流程。​​3.执行策略与模型选择​•第一次没有直接要求 Agent 进入大规模批量生成,而是先让它完成整个配置流程的打通验证。​•这类任务逻辑复杂度不高,但执行链条很长,因此选择 GPT" + }, + { + "group": "创新组", + "sender": "韦译", + "time": "2026-05-18 20:58:05", + "url": "https://dianchukeji.feishu.cn/wiki/PXVywSG2bisQxskF9i1cQSqGndb", + "content": "日报-韦译输入“/”快速插入内容2605018日报-韦译​用户6299用户62995月18日修改1.工作内容概述​1.完成类《浪漫餐厅》的解锁格子机制​2.把目前的小型闯关制度,改成类《浪漫餐厅》的大型关卡长时间推进机制(是一个比较大的功能,还在推进中,预计明日完成)​3.游戏内ui继续改进:订单区域背景图、餐桌、餐盘​4.根据实践经验继续沉淀美术工作流:喵吉托平台和gpt image-2各自有各自擅长的场景​5.研究并整理AI原生的配置方案​2.进度​2.1 完成类《浪漫餐厅》的解锁格子机制​◦简单分析可知,《浪漫餐厅》的棋盘格子有以下机制:​一 四种类型的格子:可直接解锁的格子,锁住的格子,无物品的可合成格子,有物品的可合成格子。​二 可直接解锁的格子中的物品,可以直接二合;同时,把临近一格的锁住的格子,变成可直接解锁的格子。之后,这个格子变成有物品的可合成格子。​◦复刻效果​​2.2 把目前的小型闯关制度,改成类《浪漫餐厅》的大型关卡长时间推进机制​◦简单分析可知,该机制的规则大致如下​▪概述:玩家在home场景和game场景可以来回切换,切回game场景时保留原来game场景的进度;整个game场景的关卡游玩时间比较长,长达几个小时。​▪棋盘中初始的物品布局​•中间是少量的无物品的可合成格子和有物品的可合成格子作为初始格子,目前暂时设定为9个初始格子,这9个格子是互相连接的,不能有间隔;​•周围是可直接解锁的格子和锁住的格子,并且遵循可直接解锁的格子在内层,锁住的格子一般在外层的规律。​•目前的实现不注重关卡设计和数值设计的实现,优先实现功能。第一关重点验证大型关卡长时间推进机制和棋盘的渐进式解锁格子机制,能够保证玩家从初始格子一步步拓展到其他格子,能够正常游玩下去即可。​▪关卡存档继承:在home场景和game场景切换时,能够继承原有的game场景进度​2.3 游戏内ui继续改进:订单区域背景图、餐桌、餐盘​◦使用image2生成了订单区域背景图、餐桌、餐盘​" + }, + { + "group": "创新组", + "sender": "刘鹏", + "time": "2026-05-18 20:03:00", + "url": "https://dianchukeji.feishu.cn/wiki/ZCzDwSm2Mi8cJJkIeHucbbcun54", + "content": "日报-刘鹏输入“/”快速插入内容2026.05.18日报-刘鹏​用户2416用户24165月18日修改一、工作内容概述​1.完成入职培训,熟悉工作环境​2.对齐团队方向和目标,明确后续的阶段性任务​3.安装配置Claude、Unity等开发工具​4.学习超休闲游戏关卡设计与 AI 管线文档,明确后续的工作规划​二、超休游戏关卡设计与AI管线文档的学习收获​学习了解了单人策划+AI工具链开发二合超休类的具体的开发标准和实施步骤,明确项目的目标是做出高质量的产品,跑通落地验证流程,对过程中产出的经验、方法论以及资产进行沉淀。做到快速验证,稳定成长。​三、环境配置​对于codes等一些无特殊配置/配置较为简单的工具软件,可以直接借助trae分发安装任务自动完成下载和配置,降低人工精力的损耗。​四、明日计划​对头部二合游戏进行初步筛选,确定目标场景,选择3-4款产品,借助AI深度分析,产出设计计划。​​" + }, + { + "group": "创新组", + "sender": "徐锐", + "time": "2026-05-18 18:59:00", + "url": "https://dianchukeji.feishu.cn/wiki/KQ98wIYoJiljDFkoqrfcXf5bnme", + "content": "日报 徐锐输入“/”快速插入内容2026-05-18-日报 徐锐​用户2199用户21995月19日修改1.工作内容概述​a.新人入职培训与电脑环境搭建​b.超休闲游戏制作方向文档学习​c.merge类产品初步调研与思考​2.成果​​merge产品对比快速拆解与分析​3.心得收获​a.AI学习与开发流程:更加细致地了解了超休闲游戏的开发具体流程与现在前沿的AI方案​b.合成产品设计思考:通过对比游玩多款合成类产品对这类产品的设计方向有了大致的认知,有些merge的成功产品个人感觉还是有一些设计缺陷:​i.2.Merge Cooking和Tasty Travels阴影遮挡的设计会造成视觉欺骗,让玩家觉得自己犯了低级错误从而降低乐趣​4.明日计划​思考关卡实现方式与AI生成尝试​​" + }, + { + "group": "创新组", + "sender": "韦译", + "time": "2026-05-18 14:05:56", + "url": "https://dianchukeji.feishu.cn/wiki/NSL8whlPbi4Bcmkr0xfcnVcLnxc", + "content": "内容疑难杂症​用户6299用户62995月18日修改​" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-16 00:53:59", + "url": "https://dianchukeji.feishu.cn/wiki/VQxswUOvaiUx36kPiq6cNBERnLg", + "content": "日报-王雨默输入“/”快速插入内容2025.5.15-日报-王雨默​用户2965用户29655月16日修改一.工作内容概述​•继续探索 UI 生图工作流,重点补充 Responses API / Image API 相关认知,并测试中转站 Responses API 接入效果;尝试 asset sheet 合批生成策略,验证其对多元素 UI 资源交付效率提升程度。​•修复项目在抖音开发者工具环境下暴露出的拼图海报渲染、飞行动画和广告刷新相关问题。​​​二.UI生图工作流探索​1.Responses API 认知补充​昨日判断的修正​昨日在分析 Codex 与 ClaudeCode 的生图交付质量差异时,曾倾向认为 Codex 之所以能够更好地完成“从效果图中拆分元素”,可能是因为 Codex 内部可以直接调用 Responses API 图像工具链。​今天进一步探索了解后发现,这个判断需要修正。​更准确的理解是:​•OpenAI 图像生成能力可以通过 Image API 或 Responses API 使用;​•Responses API 的图像工具可以在上下文中接收文本和图片输入,并通过image_generationtool 生成或编辑图片;​•但 Codex 内置 imagegen 并不等同于直接调用/v1/responses;​•如果要让 Codex 在工程脚本中调用 Responses API,仍然需要可用的 API Key、baseURL,以及对应的/v1/responses接口能力。​因此,昨日关于“Codex 可能直接调用 Responses API”的判断并不准确。今天先补齐了这部分认知,将几类能力重新区分清楚​​Image API 与 Responses API 的区别​梳理了 Image API 和 Responses API 的区别:​•Image API 更适合直接的图片生成或编辑任务,通常是:输入 prompt->生成图片->返回图片结果​•而 Responses API 更适合对话式、多步骤、多模态上下文中的图像任务。它更强调上下文理解、工具调用和多轮交互。​这也解释了为什么昨天观察到:​•Codex / 网页 GPT 类链路更像是先对任务进行理解和转译,再执行图像生成或编辑;而 ClaudeCode 直接调用 image2 时,如果缺" + }, + { + "group": "创新组", + "sender": "韦译", + "time": "2026-05-15 23:57:00", + "url": "https://dianchukeji.feishu.cn/wiki/WnGawSdJHixT8NkzanRc2JsFnbg", + "content": "日报-韦译输入“/”快速插入内容2605015日报-韦译​用户6299用户62995月15日修改1.工作内容概述​1.推进开发进度:今天主要调整局内UI复刻《浪漫餐厅》布局​2.生成并接入局内游戏界面ui的美术资源​3.梳理自己的程序策划工作流​4.遇到并解决了2个严重影响开发速度的问题:codex网络连接问题以及cocos控制台报错问题​2.进度​2.1 调整局内UI复刻《浪漫餐厅》布局​◦通过拆解《浪漫餐厅》布局,绘制2d简易布局图,快速实现了整体布局的复刻。但是还有一些细微的瑕疵需要调整​◦修复了关卡系统的bug问题,之前会因为空值问题,无法重玩关卡也无法进入下一关。​2.2 生成并接入局内游戏界面ui的美术资源​◦用喵吉托的AI美术平台,生成了人物半身立绘,用于在游戏中展示订单所有人。​" + }, + { + "group": "创新组", + "sender": "卓泽", + "time": "2026-05-15 23:04:17", + "url": "https://dianchukeji.feishu.cn/wiki/QWWCwp79SiwAV2ky2RDcufDCnxe", + "content": "日报-卓泽输入“/”快速插入内容20260515-日报-卓泽​用户4681用户46815月15日修改2026.5.15 日报​一、 工作内容概述​•今天主要是开发, 重构了战斗落体逻辑, 打通了包含敌人生成、武器战斗、广告激励及存档在内的完整游戏循环,差美术填充即可进入完全可玩阶段。实现50级武器视觉自动循环与粒子特效, 方便后续开始做资产之后填充, 还修正了敌人格在战斗开始时的瞬移和颜色突变问题​​二、 体验调优​按照合了个合的战斗逻辑进行了重构, 每把武器现在从各自的棋盘格位置独立起跳落体,不再成列排队移动,武器在触碰阻挡敌人时立即触发回弹;同时限制镜头仅向下推进,避免了因武器反弹导致的镜头无序弹跳。​视频▼​三、 项目进度评估​•当前进度正常, 进入系统微调, 补充开发, 填充资产的阶段, 预计下周一/二可以有包含完整美术资产填充版本​四、 明天打算做​•生成并且打磨美术资产, 配置并且调整UI布局​​​​" + }, + { + "group": "创新组", + "sender": "卓泽", + "time": "2026-05-15 00:11:41", + "url": "https://dianchukeji.feishu.cn/wiki/XylZwP9vcirf8bkffnjcbN1onpf", + "content": "日报-卓泽输入“/”快速插入内容20260514-日报-卓泽​用户4681用户46815月15日修改一、 工作内容概述​•今天主要还是开发完成了战斗结果相关的系统开发以及测试​•完成了相关系统的开发。支持限时广告开启、累积次数永久解锁、以及资源不足时的广告奖励位​•按照新的设计实现了金币、棋盘武器、关卡进度、生成器与修为进度的存档保存​​二、 核心玩法​进展如视频, 实现了战斗相关的数值系统, 金币的获取以及管理的所有逻辑, 修仙相关的逻辑, 武器生成器逻辑与熔炼销毁逻辑并且初步配置了UI资产后续进行比例细调▼​​三、 项目进度评估与后续计划​当前进度还算正常,按计划推进中, 目前正在进行的“战斗+存储+无限循环”核心模块,预计在 5 月 19 日 之前完成全部游戏流程的跑通​​四、本日研究的项目​ClaudeCode的上下文管理系统​学习自​https://github.com/win4r/cc-notebook/blob/main/Claude_Code%E4%B8%8A%E4%B8%8B%E6%96%87%E5%8E%8B%E7%BC%A9%E7%AE%97%E6%B3%95%E6%B7%B1%E5%BA%A6%E5%88%86%E6%9E%90.md由于年初的ClaudeCode泄露事件,后续许多Agent都使用了Claude的上下文管理机制,基于对 Claude Code 上下文管理系统的分析,可以知道为何Claude Code能在高度保留i信息的情况下压缩上下文​1.四层式压缩结构​Claude Code 的压缩哲学是:尽可能用廉价的规则操作延迟昂贵的 LLM 调用,只在不得已时丢弃信息。​•第 1 层:微压缩,随时触发,清除无用的工具调用信息和大段可被摘要的结构化数据​每一轮对话前的“随手清理”。它通过规则引擎,精准识别并抹除过时的、大块的工具输出(如文件读取、Shell 结果),仅保留语义锚点。这种复杂度的操作不消耗任何 API Token,却能维持极高的上下文效率。​•第 2 层:自动压缩监测,在距离模型极限(如 200K)还剩约 1.3 万 Token 的缓冲地带时强制触发。它内置了“断路器(Circuit Breaker)”机制,防止在复杂任务中陷入无效的重复压缩。​◦自动压缩监测选择性触发两种压缩:​▪第 3 层:Session Memory" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-14 23:30:28", + "url": "https://dianchukeji.feishu.cn/wiki/QAdawW4l4iaWSIkf0jDcqVxqngb", + "content": "日报-王雨默输入“/”快速插入内容2026.5.14-日报-王雨默​用户2965用户29655月14日修改一.工作内容概述​•基于昨日进度,继续探索生图工作流优化方向,重点尝试解决从整体 UI 效果图拆分单个素材时,单个素材无法完全还原效果图样式的问题。​•了解抖音开发者平台相关流程,将 Cocos 项目构建后导入抖音开发者工具,并针对抖音环境下暴露出的各种问题进行排查与修复。​​二.生图工作流探索​之前的测试发现,ClaudeCode在后续拆分阶段使用 image2 对单个元素进行重新生成,只能保证风格统一,却无法保证样式还原,初步怀疑是提示词和拆分策略的原因。​因此今天分别使用Codex和ClaudeCode,基于相同提示词、相同参考图,连续执行了三次拆分任务,用于观察两者在稳定性与还原度上的差异。​1.测试结果​对比项​Codex原生环境​ClaudeCode 调用 Image2​多次输出稳定性​稳定​较稳定​风格一致性​稳定​较稳定​与效果图还原度​几乎完全还原效果图​只能做到风格相近​资产细节​保留度更高​容易发生重构​中文文字 / 图标细节​清晰还原​容易变形或重写​同样是使用Image-2,但Codex的输出更符合“从效果图中拆出元素”的目标。​效果图​claudecode第一次​50%claudecode第二次​50%codex第一次​50%codex第二次​50%2.问题分析​关键差异不是“生图与抠图”​初期曾认为:​•Codex = 程序化抠图 + 后处理​•ClaudeCode = image2 重绘​但经过进一步分析,这个判断并不完全准确。​更准确的结论是:Codex 也是使用了生图能力,但它更像是通过对话式 agent + 图像工具链来完成任务;ClaudeCode 则更像是直接裸调用 image2 的 generation 接口。​​OpenAI 官方图像文档中明确区分了两类能力入口:Image API和Responses API 图像工具:​•Image API 包含 generations 与 edits 两类端点,前者用于从文本 prompt 生成图像,后者用于基于已有图像进行修改;​•而 Responses API 更适合“对话式、多步骤”的图像体验,并且可以把图像输入和输出保留在上下文中。​" + }, + { + "group": "创新组", + "sender": "韦译", + "time": "2026-05-14 21:49:03", + "url": "https://dianchukeji.feishu.cn/wiki/OqVjwMswbiMXHukGZZZcc9g3nnc", + "content": "日报-韦译输入“/”快速插入内容2605014日报-韦译​用户6299用户62995月14日修改1.工作内容概述​1.对Meow Art游戏美术生成平台进行调研和尝试​2.推进二合项目的基础功能的开发​2.对Meow Art游戏美术生成平台进行调研和尝试​Meow Art是喵吉托工作室推出的一款AI游戏美术生成工具,主要功能包括创建2d像素美术资源、2d高清美术资源、游戏音效资源。其中主打的类型是:角色素材和icon资源。并且还具有API拓展能力,后续能够接入自制的ai美术工作流中。​2.1 角色素材​包括静态角色和动态精灵图,有像素风格、高清风格​◦特点:动作流畅,并且细节清晰,人物一致性强。​2.2 icon资源​◦特点:ai味很弱,几乎看不出是ai生成的;并且自带透明背景,不需要自行抠图;细节丰富的同时,风格极其一致。​2.4 尝试​使用高清风格,为当前的二合项目生成了一批icon,效果非常不错。​" + }, + { + "group": "创新组", + "sender": "韦译", + "time": "2026-05-14 01:15:59", + "url": "https://dianchukeji.feishu.cn/wiki/DSD4wa3wBiXGxqkg87icUiHHnoe", + "content": "日报 韦译输入“/”快速插入内容2605013日报 韦译​用户6299用户62995月14日修改一、工作内容概述​1.对AI全栈工作流进行梳理,明确重点研究方向​2.项目的前期准备与开发​3.遇到并解决的几个坑:1 claude限额 2 codex网址配错、3 cocos mcp问题​二、AI全栈工作流的梳理​从目前开发实践经验来看,目前AI全栈开发工作流主要分为以下几大方向​一 从策划设计到程序实现的工作流​二 从概念到资产的美术包装工作流​三 针对某个特定内容的工作流​例如:就本项目的二合游戏而言,怎么利用ai生成合理的关卡而不靠传统的模板库或者手工生成,就是一个特别值得研究的方向。​目前在考虑本项目中,应当重点沉淀哪个工作流。​1.如果重点沉淀美术包装工作流,则需要和雨默错开,他正在研究一套高可自定义的工作流。个人认为可以调研第三方的美术工作流拓展视野,例如meow art。​2.如果重点沉淀从策划设计到程序实现的工作流,则优先梳理当前自身程序策划的工作流,总结优缺点。​3.如果重点沉淀针对某个特定内容的工作流,个人认为是比较具有挑战但非常有价值的。但沉淀这种类型的工作流需要在功能完善的demo的基础上才能测试,迭代优化。​​目前的结论是:个人目前优先梳理自身程序策划的工作流,再尝试以第三方平台为基础的美术包装工作流,后期有完善的demo功能后再研究怎么利用ai生成二合游戏的关卡​​三、项目的前期准备与开发​今天主要完成了:搭建Cocos项目,接通MCP到Claude Code和Codex中,开发二合项目的基础功能:棋盘与合成系统、订单+关卡系统、经营系统与主界面UI​乐观预计明日完成基础功能开发,后天能接入第一版的美术资源。​​四、下一步计划​1.尝试多个ai美术工作流给当前的二合项目生成美术资产,进行一次调研​2.继续完成二合项目的基础功能开发​​​" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-14 00:05:02", + "url": "https://dianchukeji.feishu.cn/wiki/VFeCwF4VsizD4Bkri2Rc62junbf", + "content": "日报-王雨默输入“/”快速插入内容2026.5.13-日报-王雨默​用户2965用户29655月14日修改一.工作内容概述​•完成抽奖系统剩余部分逻辑,修复bug​•测试生图Skill进阶模式执行链路,并对其进行优化​二.生图Skill进阶模式测试优化​1.测试情况​最开始几次测试时,发现流程并没有完全按照预期运行,主要问题包括:​1.一些已经约定好的流程步骤没有被严格执行;​2.provider 的相关配置没有被持久化保存,导致多次调用之间配置不稳定;​3.某些本应向用户确认的步骤被跳过;​4.部分阶段虽然状态显示已完成,但实际中间产物并不稳定;​5.生成、拆分、后处理、交付之间的衔接还不够清晰。​经过多轮修复后,进阶模式已经能够按照预期流程运行,并最终完成图片资产交付。但在当前默认链路下,交付质量、资产风格一致性以及对参考图的还原度仍然不够稳定。​也就是说,进阶模式现在已经具备基本交付能力,但还需要继续优化生成链路的可控性和稳定性。​前期资产清单确认​50%生成报告,尺寸有bug,后面修复了​50%效果图​交付图,整体风格符合概念图,但是样式没有按照效果图进行还原​2.质量问题与初步判断修正​问题不一定出在底层模型能力本身,而可能出在调用链路、提示词编译、任务拆分方式、参考图传递方式,以及 skill 工作流对生图任务的组织方式上。​也就是说,即使底层模型同样是 image2,最终效果也可能因为前置 agent、provider 封装层、参数暴露方式、prompt 编写方式不同而出现明显差异。调用同一个生图模型,不代表最终效果一定等价。​原生 ChatGPT 网页端的生图效果较好,可能不仅是因为底层模型强,也因为它在用户输入和生图模型之间,存在更强的任务理解、prompt 优化和调用编排能力。第三方 agent 如果只是把用户原话简单拼接后交给模型,即使模型相同,结果也可能不稳定。​所以当前要解决的核心不只是 provider 能不能调用 image2,而是:第三方 agent 能不能像原生 GPT 一样,把用户的模糊需求转译成适合生图模型执行的高质量 prompt。​3.拆分生成测试与发现​为了进一步定位资产质量问题,今天使用一张完整的游戏抽奖界面进行了拆分生成测试。​最开始版本生成出的资产并不是完全跑偏,整体风格与参考图是接近的,例如水彩质感、柔和配色、手绘" + }, + { + "group": "创新组", + "sender": "卓泽", + "time": "2026-05-13 22:15:01", + "url": "https://dianchukeji.feishu.cn/wiki/GfgYwRD7Yiyac0kVWOtc9WFjn2c](https://dianchukeji.feishu.cn/wiki/GfgYwRD7Yiyac0kVWOtc9WFjn2c)", + "content": "Access DeniedX-TT-System-Error: 3Oncall ID: 783" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-13 02:14:15", + "url": "https://dianchukeji.feishu.cn/wiki/U32FwRkZPiYu9vkEtXPcRNVVnSe", + "content": "日报-王雨默输入“/”快速插入内容2026.5.12-日报-王雨默​用户2965用户29655月13日修改一.工作内容概述​•抽奖系统核心逻辑实现,包括抽奖入口、奖励配置读取、抽奖结果生成与基础状态流转。​•优化生图工作流,引入第三方后处理抠图 provider,调整透明背景处理策略。​​二.生图工作流优化​1.引入第三方后处理抠图服务​之前Skill的后处理主要依赖本地脚本,比如纯色背景抠图、边缘清理、去杂边、透明通道修复等。这套方式对简单 UI 元素基本可用,但在复杂素材上,本地处理的输出质量上限较低。​对韦译分享的网站https://www.koukoutu.com/进行了测试,发现其能够承担复杂图片的抠图工作、输出边缘清晰的透明背景png图片,且提供开发者API。现尝试将其引入生图工作流中。​2.新工作流优化​暂时去除了之前“纯色背景生成 + 本地脚本抠图”的流程,而是优先使用原生透明图;如果没有可靠透明背景,则使用第三方抠图服务。​这次调整的核心意义在于:​•去掉了对纯色背景的依赖;​•去掉了本地脚本抠图带来的不稳定因素;​•提高复杂素材透明背景的质量上限;​•减少本地参数调试成本;​•让后处理流程更依赖高质量 provider,而不是本地规则脚本;​•为后续扩展不同后处理 provider 留出空间。​3.生成策略分级​为了适配不同任务,尝试将Skill分为了三个模式:​•快速模式​•标准模式​•进阶模式​分别承担不同复杂度的生图需求。​快速模式​快速模式主要用于快速验证方向或是简单的资源生成。​流程可以简化为:​1.生成图片​2.简单检查透明背景​3.必要时调用第三方抠图服务​4.快速质量检查​如果结果可用,就直接输出;如果结果明显不可用,再简单修复,不做复杂多轮处理。​标准模式​标准模式用于常规 UI 资产生产。​流程是:​1.生成图片​2.检查透明背景​3.优先保留原生透明背景​4.必要时调用第三方抠图服务​5.尺寸调整、预览生成和质量检查​6.质量检查​7.打包输出​这个模式是后续大多数 UI 资产生成的默认模式。​它的重点是:​•保证质量​•控制成本​•减少不必要的重复处理​•让每个素材选择合适的处理方式​进阶模式​" + }, + { + "group": "创新组", + "sender": "韦译", + "time": "2026-05-12 22:48:57", + "url": "https://dianchukeji.feishu.cn/wiki/IGr9wUHPUi6dMwkE1s6cVKPfnGe", + "content": "内容在Claude Code中使用AWS的API​用户6299用户62995月13日修改1 下载并安装AWS CLI​https://awscli.amazonaws.com/AWSCLIV2.msi​​2 配置aws configure​在命令行中输入:aws configure​按提示依次输入 AK、SK、区域(us-east-1)、输出格式(回车跳过)。​如下:​•AWS Access Key ID:你的 AK​•AWS Secret Access Key:你的 SK​•Default region name:us-east-1​•Default output format:直接回车​🌰这里的ak和sk,指的是AWS那边配发的Access Key和Secret Access Key,需要向IT同学申请​3 Claude Code 配置​3.1 打开claude的配置文件:​3.2 在配置文件中写入:以下内容​{​\"env\": {​\"CLAUDE_CODE_USE_BEDROCK\": \"1\",​\"AWS_REGION\": \"us-east-1\",​\"ANTHROPIC_MODEL\": \"us.anthropic.claude-opus-4-6-v1\",​\"ANTHROPIC_SMALL_FAST_MODEL\": \"us.anthropic.claude-haiku-4-5-20251001-v1:0\",​\"HTTP_PROXY\": \"http://127.0.0.1:1080\",​\"HTTPS_PROXY\": \"http://127.0.0.1:1080\"​},​\"skipDangerousModePermissionPrompt\": true,​\"includeCoAuthoredBy\": false​}​🏆这里的http_proxy主要是为了配置代理网络,如果不写上这2行的话,会被Claude禁止使用api​​" + }, + { + "group": "创新组", + "sender": "卓泽", + "time": "2026-05-12 22:48:29", + "url": "https://dianchukeji.feishu.cn/wiki/ZKeNw6V9ViwCH3kyAM9cOYSpntf", + "content": "日报-卓泽输入“/”快速插入内容20260512-日报-卓泽​用户4681用户46815月13日修改2026.5.12 日报​一、工作内容概述​•在昨天跑通基础游戏循环的基础上,继续推进二合增量游戏从可玩到完整过渡,重点完善存档、测试控制台、Prefab 接入、金币生成逻辑和 UI/资产替换流程。​•封装了一个可供 AI 稳定调用的图像抠图工具,支持输入图像并输出透明底素材,为后续 AI 生成美术资产后的自动化处理做准备。​•配通 Amazon Bedrock Claude 4.6 在 OpenCode 中的调用方式,并初步配置试用 Codex/goal,继续补齐 AI 辅助开发工具链。​•整理并写入 SO 配置与开局接入说明文档,用于后续规范项目配置、UI 皮肤、合成物素材和大等级链条的接入方式。​二、工具链与资产生产​2.1 AI 抠图工具封装​今天封装了一个输入图像、输出透明底图片的工具,基于https://sync.koukoutu.com/v1/createAPI 实现。这个工具后续可以作为 AI 美术生产链路的一部分:当 AI 生成角色、建筑、道具或 UI 元素后,可以自动调用抠图工具得到透明底素材,经过测试处理效果非常令人满意, 十分方便后续进入 Unity 项目进行配置或二次处理。​这类工具本身不直接等同于游戏功能,但对 AI 全栈开发很关键。因为 AI 生成素材经常会带背景、边缘或不稳定格式,如果每次都人工处理,会打断开发节奏。把它封装成稳定工具后,后续可以并入节点流程,让“生成素材 -> 抠图 -> 导入项目 -> 配置测试”这条链路更接近自动化。​remove_bg.py5.27KB处理的UI对比​50%50%2.2 Bedrock Claude 4.6 接入 OpenCode​今天还配置并验证了 Amazon Bedrock Claude 4.6 在 OpenCode 中的调用方式。由于 AMS比较特殊的认证机制(需要单独配置)以及其地区限制, 需要修改配置文件,在参考了韦译的修改以及查阅了 OpenCode 文档之后,并进行了多轮配置调整,最终调试到了可以使用的状态.​三、重点工作推进​2.1 UI 与资产接入​今天开始把测试用美术素材实际接入到项目中。当前已经支持棋盘格和合成物通过 Prefab 配置图片,并修复了运行时代码覆盖 Pref" + }, + { + "group": "创新组", + "sender": "韦译", + "time": "2026-05-12 22:47:25", + "url": "https://dianchukeji.feishu.cn/wiki/NkY6wVzfliQAyykiWsEcaN9cnue", + "content": "日报输入“/”快速插入内容2605012日报​用户6299用户62995月12日修改一、工作内容概述​1.入职培训、熟悉工作环境​2.安装开发环境和ai工具​3.跑通AWS的API接入Claude Code的流程​二、在Claude Code中使用AWS的API​​在使用api接入claude code这种agent工具的过程中,发现AWS的api不同于以往的url加key的接入方式,采用比较特殊的ak➕sk的接入方式,在熟悉这个接入方式时花了不少时间​遇到的主要问题有2个​一 不熟悉AWS的ak➕sk的接入方式​二 配置代理环境时,不熟悉具体操作:即使用ak➕sk的方式配置好了,也仍然大概率会卡在Claude code的配置代理问题(claude code需要单独配置代理)。​​在嘉辉老师的帮助下,得出临时性的解决方案如下​​在Claude Code中使用AWS的API​​三、收获与反思​1.个人对Claude code的代理配置工作有进一步的了解​2.计划编写帮助文档,帮助后入职的同学快速上手​计划:帮助文档分以下3大板块​•开发环境配置​◦主要阐述node、代理配置、命令行等开发环境的配置​•疑难杂症集合​◦大家都踩过的坑都可以简单整理成文档,甚至可以让ai自行总结。不耗功夫的同时又能帮助他人​​" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-12 00:22:24", + "url": "https://dianchukeji.feishu.cn/wiki/F8jiwgDmkiyzLMk5KYecuOjinAg", + "content": "日报-王雨默输入“/”快速插入内容2026.5.11-日报-王雨默​用户2965用户29655月12日修改一.工作内容概述​•完成皮肤系统逻辑实现​•继续探索优化Codex生图工作流​二.Codex生图工作流优化​1.GPT Image-2 即时模式​今日探索发现:GPT Image 2 的即时模式(Instant 模式)可以直接生成带真实透明背景的 PNG 图片。​这个发现说明,之前 Skill 中默认采用的“纯色背景 + 后处理抠图”流程,并不是所有情况下都必须执行。如果生成阶段本身就能输出真实透明背景,那么部分后处理抠图步骤就有机会被省略或降级。因此,今天主要围绕以下问题继续对 Skill 进行优化:​•不同生图模式在流程中应该如何分工;​•是否应优先使用真实透明背景,而不是默认纯色背景;​•是否可以接入第三方生图服务;​•是否可以通过资产图集提高批量生成效率;​•这套 Skill 是否具备迁移到其他 AI Agent 的可能。​​2.即时模式和思考模式​测试中发现,GPT Image 2 的不同生成模式有明显差异:​即时模式​即时模式的优势是:​•可以直接生成真实透明背景 PNG​•适合图标、按钮、角标、小装饰等简单或中等复杂度素材​•可以减少色键抠图带来的边缘损失​但它也有明显短板:​•细节复杂度上限较低;​•对复杂结构、复杂角色、角色立绘等控制不稳定;​•实测中,在复杂角色立绘等高细节要求的场景下,生成结果可能出现结构简化或细节丢失,稳定性不如思考模式。​因此,即时模式更适合作为简单素材生成模式,不适合作为复杂主视觉资产或角色立绘的默认生成模式。​即时模式生成的icon,真实透明背景,边缘正常​60%即时模式生成的角色立绘,放大可以发现细节部分完全不可用​40%即时模式生成的角色海报,整体质量反而优于角色立绘,推测是AI生成立绘需要花费大量成本在处理透明像素上,导致无法顾及其他部分​​思考模式​思考模式的优势是:​•更适合整体效果图;​•更适合复杂布局、风格统一、视觉层级控制;​•对角色、装饰、整体氛围等复杂内容把控更好。​但它的问题是:​•不能输出真实透明背景 PNG;​•如果用于单资产生成,通常仍需要依赖色键抠图或其他后处理方式。​因此,思考模式更适合作为整体设计和复杂资产参考模式。​​思考模式生成的UI界面效果图​46%思考模式生成的角色立绘,虽然" + }, + { + "group": "创新组", + "sender": "卓泽", + "time": "2026-05-11 20:06:34", + "url": "https://dianchukeji.feishu.cn/wiki/YmolwbdlOikKWMkGgQmcTflMnQe", + "content": "日报-卓泽输入“/”快速插入内容20260511-日报-卓泽​用户4681用户46815月12日修改一、工作内容概述​•基于前期架构文档正式启动二合增量游戏的编码实现,按照完整架构思路搭建了包含完整核心系统边界的 MVP 原型​•创建对应测试 Scene 进行运行验证,完成棋盘、合成、资源、任务、UI 与测试工具等基础链路的调试​•复盘此前 API Key 异常用量问题,并且了解了背后的隐式思维链模型的技术基础​二、重点工作推进​2.1 完整架构 MVP 原型编码​此前已经完成二合增量游戏的整体系统拆分与核心流程设计,今天开始将这些结构落实到工程中, 从架构设计文档进入实际开发,目标不是先写一个孤立的小 Demo,而是在 MVP 阶段尽早按完整架构搭出可运行的基础骨架,方便后续逐步替换表现层、补充素材和扩展系统。​本次已按照架构创建并接入了核心游戏框架代码,覆盖棋盘、合成、资源、任务、UI、存档和运行时测试辅助等模块。当前测试 Scene 已能在完整架构下运行,支持基础棋盘显示、物品生成、拖拽、合成、资源变化和任务反馈等流程,为后续继续迭代玩法、表现和数据配置提供了可验证基础。​开发过程中也同步处理了多项会影响原型验证的问题:​•修复DontDestroyOnLoad只能作用于根对象的问题,避免运行时管理对象持久化层级不正确。​•修复运行时实例化对象继承 inactive 状态的问题,使棋盘格、生成物、任务需求和提示 UI 能正常显示。​•修复合成成功时目标格子引用被提前清空的问题,保证合成流程稳定执行。​•修复 Game 视图灰黑、运行时相机与 Canvas 配置冲突的问题,使测试 Scene 能在 Game 视图中正常显示。​•修复拖拽时坐标系不一致导致物品瞬移偏移的问题,使拖拽交互能按鼠标位置稳定跟随。​•将布局方向调整为手机竖屏,并重新整理棋盘、任务面板、体力条和生成按钮的位置关系。​至此, 核心系统逻辑已经基本跑通​2.2 测试工具与表现层准备​下一步打算重构PrototypeSceneSetup.cs,并将棋盘、物品、任务面板、按钮和测试控制台等表现层对象逐步 Prefab 化。这样既能保留已经跑通的逻辑层,也能让后续美术素材填充、布局调整和交互动画接入更加稳定。​三、探索与复盘​3.1 API Key 异常用量原因复盘​今天复盘了此前 API Key " + }, + { + "group": "创新组", + "sender": "卓泽", + "time": "2026-05-10 11:34:30", + "url": "https://dianchukeji.feishu.cn/wiki/RdWtwxGwPi4DRzkhpOEc6S84nsf", + "content": "日报-卓泽输入“/”快速插入内容260509-日报-卓泽​用户4681用户46815月11日修改2026.5.9 日报​一、工作内容概述​•调研 AI Skill 生成器工具(dot-skill 与 nuwa.skill),完成对标分析。​•基于 dot-skill 部署 colleague-game-tdd-writer Skill,用于将游戏核心设计要素、策划案与目标引擎转化为结构化系统架构与技术策划文档。​•使用该 Skill 完成二合增量游戏的完整架构设计文档(v0.3),输出包含 Mermaid 流程图、配置表定义、MVP 范围划定及边界条件覆盖。​二、重点工作推进​2.1 背景与目标​下一阶段将启动一款二合(Merge-2)增量循环类休闲游戏的 AI 全栈开发,引擎为 Unity 6(UI Toolkit)。在正式编码前,需要将零散的设计思路转化为系统化的技术策划文档与架构蓝图,以降低开发过程中的方向偏移和返工。本次尝试用定制化 AI Skill 自动化\"设计概要 → 架构文档\"这一环节。​2.2 今日完成内容​1.Skill 生成器调研​对比了 dot-skill 与 nuwa.skill 两款工具:​​结论:dot-skill 在\"领域知识注入 + 结构化文档生成\"方面更适合当前需求,选定为 Skill 基础框架。​2.Skill 部署与文档生成​基于 dot-skill 部署 colleague-game-tdd-writer,工作流程如下:​代码块​Plain Text设计概要输入 → Skill 多轮确认(5项关键决策) → 生成完整架构文档​创建了skill, 希望后续能够通过skill标准化这个过程:​colleague-game-tdd-writer.zip​人工确认的 5 项关键决策:​•资源消耗:暂定仅体力,保留消费类型枚举扩展​•任务包装:MVP 用 MergeOnly 纯提交模式,塔防/挖矿留给 P1​•合成倍率:从全局常量升格为配方级,每条链每级独立可配​•棋盘尺寸:运行时动态生成,参数驱动(2×6 ~ 9×7),改参即生效​•剧情系统:补充完整触发点设计(storyId 方式 + StoryTrigger 独立配表)​3.架构文档核心内容​生成的 v0.3 文档覆盖以下模块:​整体架构设计▼​" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-10 03:02:35", + "url": "https://dianchukeji.feishu.cn/wiki/EpZZw1rT9iBZDFkrwo2cgImpngb", + "content": "日报-王雨默输入“/”快速插入内容2026.5.9-日报-王雨默​用户2965用户29655月10日修改一.工作内容概述​•碎片收集系统功能收尾,bug修复​•参照agent-sprite-forge项目,仿写 Codex 生图 Skill​​二.参考项目学习分析​参考了agent-sprite-forge项目的设计思路。该项目的核心并不是简单提供一组 sprite prompt 模板,而是提供了一套面向 Agent 的 2D 游戏资产生产流程。​参考项目:https://github.com/0x0funky/agent-sprite-forge​它的基本工作方式是:​代码块​Plain Text用户提出 sprite / map / prop 等资产需求​↓​Agent 理解需求,判断资产类型、动作、帧数、布局和风格​↓​Agent 调用自身可用的 image generation 能力生成 raw asset​↓​Python 本地脚本进行后处理​↓​输出可用于游戏工程的 PNG / GIF / metadata​其中最值得参考的是它对职责的拆分:​•Agent 负责创意判断和流程决策​•图像模型负责生成原始视觉结果​•Python 脚本负责确定性的工程处理​也就是说,参考项目并不指望 AI 一次性输出完美工程资产,而是让 AI 负责视觉生成,再通过脚本完成:​•去背景​•despill​•切帧​•对齐​•统一缩放​•透明导出​•GIF 预览​•metadata 输出​•QC 检查​这种设计思路比较适合迁移到 UI 资产生产中。因为 UI 资产同样存在“视觉生成”和“工程可用”之间的断层:AI 可以生成好看的 UI 效果图,但要进入项目使用,还需要拆分、透明化、去边缘污染、统一命名和质检。​三.Codex Skill仿写思路​基于参考项目,本次没有直接照搬 sprite 生产流程,而是提取其核心模式:Agent原生生图能力+本地确定性后处理,然后将其迁移到静态 UI 资产生产中。​两者的对应关系大致如下:​因此,这个Skill的核心目标被定义为:​将 AI 生成的 UI 效果图,进一步转化为可交付的独立透明 PNG 资产包。​而不是只停留在“生成一张完整 UI 图”。​四.Skill 最终流程设计​设计的Skill流程如下:​1.需求确认​2.整体 UI 效果" + }, + { + "group": "创新组", + "sender": "卓泽", + "time": "2026-05-09 06:29:32", + "url": "https://dianchukeji.feishu.cn/wiki/CHZiwHehNizCJKkhZqccilaknMd", + "content": "日报-卓泽输入“/”快速插入内容260508-日报-卓泽​用户4681用户46815月11日修改一.今日工作内容概述:​•对抖小/微小排行榜头部休闲品类(重点针对二合及AI适配度)的发散调研结束, 进入二合核心玩法的开发阶段​•游戏具体系统拆解与架构与设计(部分完成)​•Unity, Git, Opencode的开发环境配置​二.品类调研相关​微小与抖小热门榜前列的二合游戏​•​排行榜及其具体休闲品类排行榜游戏类型分析​抖小/微小休闲品类调研总结​1.二合品类现状:​◦目前排行榜头部的二合(如《浪漫餐厅》、《四季合合》)基本被“二合+剧情+线性装修”的框架垄断,微小端同理。《Travel town》虽然混变,但大循环基本相同,二合占比稍多。​◦发现的高优适配方向:抖小前列的《合了个合》。这类IAA属性强,游戏复杂度适合作为第一步入手点,且玩法驱动模型更适合AI后续介入开发。​画板2.其他高适配度/AI提效潜力品类 储备记录:​◦箭头消除/车辆消除(如《超级消消》、《套住那只羊》):双端热门,其资产开发、关卡设计极具扩展性,非常适合AI高度介入,复杂度适中。​◦一笔画/画之谜:抖小热门前列。关卡生成本质为欧拉图创建+图形绘制,有望依靠AI实现自动化关卡生成。​◦AI互动影游(如《显眼包本包》):天生的IAA品类,资产可依靠工作流与专用模型批量生产并配置进不同剧情分支。​◦高数据表现但AI关卡生成较弱的品类:新型Match2消除(《砖了个砖》)、消除+物理效果(《消个水果》)、拧螺丝+消除+物理(《拯救牛牛》)。此类品类AI提效空间大,但关卡生成的自动化AI介入提升空间不大​三. 后续开发规划​根据今日沟通的明确方向,结束发散进入二合核心玩法的开发阶段。从“二合”核心玩法入手。搭建二合玩法的最基础底层框架(棋盘网格生成、基础物品生成器逻辑、拖拽与合并判定等系统及功能)。先让核心玩法跑起来,在实际开发过程中去搭建开发管线并暴露问题, 解决问题, 并且做好记录.​​" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-09 01:33:11", + "url": "https://dianchukeji.feishu.cn/wiki/NzSOwDHlgiPCx9klcKWcxzawnhe", + "content": "日报-王雨默输入“/”快速插入内容2026.5.8-日报-王雨默​用户2965用户29655月9日修改一.工作内容概述​•持续推进碎片收集系统进度​•尝试使用AI制作图片处理工具,解决之前遇到的“边缘问题”​二.图片处理工具​问题背景​在之前的尝试中,AI生成的单个按钮、图标或面板,视觉上看起来可用,但边缘像素通常不适合直接作为游戏资源使用,体现在如下方面:​•背景不是真实透明背景,而是被绘制上去的真实像素。​•使用AI进行抠图无法解决边缘问题,产出的图片边缘存在大量瑕疵,完全无法使用​尝试思路​尝试使用AI编写工具来进行资源的处理,思路如下:​1.临时背景识别色​使用特定颜色(如洋红色#FF00FF) 作为临时背景识别色工具通过这个颜色判断背景区域。但不能简单地把所有接近#FF00FF的像素都删除,因为素材内部也可能有粉色、紫色高光或装饰。因此需要通过“外部连通区域”来识别真正背景。​2.保留内部质感,清理外部污染​处理原则是:​也就是说,目标不是把素材变成纯扁平图形,而是把它处理成:主体仍然有质感,但外部轮廓干净、透明、无紫边。​3.高像素输入后再缩放导出​如果输入图是高像素版本,例如目标尺寸的 3 倍或 4 倍,工具可以先完成边缘处理,再缩小到目标尺寸。​这样可以减少:​◦紫边;​◦锯齿;​◦AI 生成噪点;​◦边缘不稳定像素。​但也要注意:​◦小高光可能变弱;​◦极细描边可能变淡;​◦图标细节可能略糊。​所以缩放需要使用高质量算法,并允许轻微锐化。​​流程原理梳理​1.颜色距离检测:判断像素是否接近背景色​工具首先计算每个像素与#FF00FF的颜色距离。​背景色为:​代码块​Plain Text#FF00FF = RGB(255, 0, 255)​颜色距离计算:​代码块​Plain Textdistance = sqrt((R - 255)^2 + (G - 0)^2 + (B - 255)^2)​距离越小,说明像素越接近背景色。​这一步的作用是:​•识别纯背景像素​•识别接近背景色的混色像素​•辅助判断紫边污染​不会直接删除像素,只是生成“背景候选区域”。​2.泛洪填充:只识别外部背景​仅靠颜色距离还不够,因为素材内部也可能有类似颜色。​因此工具从画布四周开始做泛洪填充:从图片四条边缘开始,找到接近 #FF00FF 的像素,向相邻像素扩散,只把与画布外部连" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-08 01:50:47", + "url": "https://dianchukeji.feishu.cn/wiki/KRxGwTZ0miRVMMk0fjPcIVv7nge", + "content": "日报-王雨默输入“/”快速插入内容2026.5.7-日报-王雨默​用户2965用户29655月8日修改一.工作内容概述​•碎片收集系统数据框架、UI初步搭建​•实现碎片拼图效果绘制逻辑​•基于昨日进度,继续尝试GPT-Image2生图​​二.碎片拼图效果实现​预期效果​1.碎片拼图视觉效果​◦碎片海报应当呈现接近真实拼图的效果,海报外边缘保持平直,内部碎片边缘呈现凹凸互补,而不是简单的矩形切图。​◦每张海报会根据配置被切分成不同数量的拼图碎片,例如 4x6、5x6、9x15 等。​◦不同切分数量下,碎片形状可以不同,但海报内容必须保持连续。同一张图片在同一归一化位置上的采样内容应保持一致,不会因为碎片数量变化导致整张图案整体偏移或每片独立拉伸。​​2.轮廓线表现​◦轮廓线只用于表达“未收集区域”的拼图形状,不干扰已经收集到的海报内容。​◦已填充碎片不显示轮廓线,避免完整海报画面被线条切碎。​◦玩家已经收集到的区域应当更像真实图片,而不是一堆被描边的小块。未填充碎片继续显示拼图轮廓,用来提示剩余空位的位置和形状。​◦轮廓线应当粗细稳定、透明度一致。相邻未填充碎片之间的共享边只绘制一次,避免左右或上下两个碎片重复描边,导致线条叠加变粗、变亮。​​3.飞入填充动画​◦新获得并分配的碎片不会直接瞬间出现在海报上,而是通过飞入动画表现“获得并填入”的过程。​◦动画开始前,目标位置仍然显示为空位轮廓。系统会创建一个临时飞行碎片,让它从碎片入口或广告按钮附近飞向目标海报位置。​◦飞行中的碎片使用与目标位置一致的拼图形状和海报贴图内容,避免出现飞行时和落地后视觉不一致的问题。当碎片飞到目标位置后,临时飞行节点会被移除,目标位置正式显示为已收集碎片,同时该位置的轮廓线消失。​◦整体流程为:碎片飞向海报 → 填入空位 → 海报内容恢复​​实现思路​1. 拼图视觉表现​拼图渲染的核心由PuzzlePosterRenderer和PuzzleShapeGenerator配合完成。​•PuzzleShapeGenerator 负责生成碎片形状。系统会根据海报的行列数和 seed 生成一张边缘表。海报外边界固定为平边,内部边缘随机生成凸起或凹槽。相邻碎片读取同一条边,但方向相反,因此可以保证凹凸关系互补。​•每个碎片最终会被转换成一组多边形点。平边直接连接,凸起和凹槽则通过曲线采样生成。为了交给" + }, + { + "group": "创新组", + "sender": "卓泽", + "time": "2026-05-07 22:56:48", + "url": "https://dianchukeji.feishu.cn/wiki/NjkVwE5b2iG9wbksmy5ciSqDnDp", + "content": "日报-卓泽输入“/”快速插入内容260507-日报-卓泽​用户4681用户46815月9日修改一.今日工作内容​•了解二合品类各类型不同的游戏, 部分调研了其他抖小排行榜前列品类的游戏​•初步体验浪漫餐厅, 初步拆解整体循环与游戏逻辑​二. 工作内容概述​​1. 《浪漫餐厅》系统循环初步拆解​《浪漫餐厅》属于典型的二合+模拟经营的复合品类。其系统融合了合成类的空间管理+经营类的长养成​画板​•循环上: 将长线的餐厅建设目标,切割为无数个即时可见的合成配方。将长线积累的模板为可视化的微小正反馈, 在合成大件产生快感的同时, 把抓马而富有悬念的剧情与线性装修作为奖励, 平滑丰富了玩家的体验曲线走出,掩盖了一般长线积累的枯燥感。通过生成器的冷却时间与体力恢复机制,控制玩家的单次游戏时长与内容消耗速度,培养碎片化登录习惯。​•背包上:棋盘的网格数量是游戏内的隐性资源约束。随着高级物品的滞留、不同生成器产出路线的交叉,空间压缩驱动玩家进行资源取舍,或通过内购(购买临时背包、加速冷却道具)来消除\"临门一脚完成合成, 却功败垂成\"的损失干。​关于二合类后续计划:​•作为IAP游戏, 许多相关资料提到浪漫餐厅的短期活动对于其营收有重要影响, 当前还没体验到对应游戏内容, 希望后续体验过程中能够截取部分进行拆解​•从借鉴角度说, 作为IAP, 是要对其进行IAA改造? 改造从什么角度入手改造? 是否考虑其他二合+品类玩法(例如? 暂时想不起来名字), 局外大量与剧情/视觉表现相关的, 去除后用什么内容衔接循环? 也许需要调研其他二合品类, 例如Travel Town这样更重玩法而非剧情与线性装饰获取大循环的​​​2 关于其他游戏品类的简单调查-休闲游戏市场品类简要机制分析​休闲游戏的本质是对人类碎片化时间中情绪变化与注意力的精细化管理。当前部分排行榜前列游戏可按系统驱动力划分为以下模块​将近期市场典型作品与上述基本盘进行横向对比,可清晰提取出其在系统设计与受众心理捕获上的分化路径:​​​" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-07 01:07:15", + "url": "https://dianchukeji.feishu.cn/wiki/FFY7wfiFaig3pMkg9H7cFobFn7g", + "content": "日报-王雨默输入“/”快速插入内容2026.5.6-日报-王雨默​用户2965用户29655月7日修改一.今日工作内容概述​•初步了解抖音平台云服务相关内容,规划后续开发内容​•完善账号数据框架相关内容,并为后续云服务接入做准备​•GPT Image-2使用尝试​​二.账号数据相关​游戏核心数据层重构完毕​•完成了“碎片收集”、“生存模式”和“皮肤系统”三大数据模块的独立拆分。​•将所有新模块统一集成到玩家主数据中,彻底清理了旧版的零散字段和废弃代码,使数据结构更加清晰。​​抖音云存档方案​•查询了解抖音云官方文档,计划以“云托管”方式接入云存档,同步输出相关设计文档和后续开发计划的修改。​•搭建了全新的本地存档管理机制,在不改变原有游戏功能的前提下,为后续连接云端搭好了框架。​​三.GPT Image-2 使用尝试​尝试目标​•通过 AI 生成与后处理方式,获得可直接用于游戏工程的,可直接交付的UI分层资源。​​尝试记录​直接生成并拆分分层 PSD 文件​•尝试内容​◦基于完整主界面效果图,尝试将画面中的 UI 元素按功能模块拆分,并输出为 Photoshop 可打开的分层 PSD 文件,目标是让每个元素成为单独图层,并保持原图中的尺寸和位置。​测试图片​•结果表现​◦PSD 文件可以生成,也可以在 PS 中打开,但实际资源质量不满足工程使用要求。​◦主要问题包括:​​​32%32%37%完整 UI 图本质上是一张合成后的图片,元素之间已经发生了遮挡、融合、抗锯齿混合和阴影叠加。后期再拆分时,只能近似抠图,无法还原成原始设计图层。​B站相关的Image-2生成分层PSD的视频演示,案例均为元素相对较少的海报图片,且没有切图资源质量展示的环节,参考价值有限。​​每个元素单独输出为透明背景 PNG​" + }, + { + "group": "创新组", + "sender": "卓泽", + "time": "2026-05-06 21:58:20", + "url": "https://my.feishu.cn/wiki/LSY7we2ceiJ5s5kOJwoclB77nXc", + "content": "日报260506输入“/”快速插入内容日报260506​用户2349用户23495月7日修改本日主要做了的事情:​今天主要做了两块事情:​1.入职准备,包括与新员工相关的入职培训通用办公环境的配置,软件安装等前期准备​2.尝试确定接下来要做的项目的主题​a.尝试进行项目组的目标对齐​b.休闲类/AI原生题材游戏的调研​c.开始撰写项目立项案初稿​本日工作总结:​今天主要还是适应环境,还有一些疑惑希望能够在后续出的初稿得到解答​" + }, + { + "group": "创新组", + "sender": "王雨默", + "time": "2026-05-01 02:38:52", + "url": "https://dianchukeji.feishu.cn/wiki/Gh8cw3QnJiplq1k2lmFcajidnHl", + "content": "日报-王雨默输入“/”快速插入内容2026.4.30-日报-王雨默​用户2965用户29655月1日修改一.工作内容概述​•开始账号数据框架搭建,完善体力系统相关功能​•工作流优化探索,尝试引入Codex审查步骤;结合Obsidian进行相关文档、开发日志整理。​​​二.工作流优化探索相关​尝试使用 Codex 插件进行功能审查​1.背景与痛点​目前中大型功能由 Agent Team 协作完成后直接提交,缺少独立的外部审查环节,即使原流程中已经有审查验证步骤,还是会有BUG遗漏。​​2.今日实践​在ClaudeCode里安装了Codex插件,在体力系统代码完成后,执行了/codex:review。Codex 作为\"外部 reviewer\",从第三方视角审查了工作树 diff,审查范围覆盖全部变更文件。​​3.效果评估​•效果&成本收益:审查耗时约 3-5 分钟,成功发现4个有效问题。​•后续考虑:将这一步骤作为复杂功能(涉及多文件改动)的固定收尾步骤​​4.待优化点​•触发方式:目前 Codex review 是手动触发(/codex:review),后续可考虑写入rules,在AgentTeam交付后自动提醒是否要启动Codex review​​Obsidian 文档与开发日志体系​1.背景与痛点​项目文档和开发日志之前分散在三个地方:​•CLAUDE.md:项目总体说明,更新频率低​•memory文件:对话上下文中的记忆片段,跨 session 易丢失​•对话上下文:即时讨论,压缩后不可回溯​这种分散导致:​•跨 session 复盘困难,需要翻阅多段对话才能还原完整上下文​•技术决策缺少归档,后续重复讨论同样问题​•待办事项散落在各处,容易遗漏​​2.今日实践​Obsidian Vault 与项目仓库联动​•将Obsidian-Vault/目录纳入项目仓库,实现文档与代码版本同步​•开发日志按日期归档,命名格式YYYY-MM-DD.md,便于按时间线回溯​​" + }, + { + "group": "dc战略问题研究院", + "sender": "胡辉俊", + "time": "2026-05-19 01:11:08", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/ErwhdZhR3oJjoNxGB85cQBicnge", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "夏莲", + "time": "2026-05-19 01:10:55", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/KlGYddZoOo2UD9xIEVgcNqQ3n5c", + "content": "日报-夏莲输入“/”快速插入内容2026.05.18-日报-夏莲​用户4109用户41095月19日修改一、工作内容概述​1.完成三份汇报文档:文字版报告、PPT报告、整改报告​2.了解学术研究Agent​​二、了解学术研究 Agent​近一年,学术 AI Agent 研究从单点辅助工具转向了“科研流程型 Agent”。主要覆盖文献检索、假设生成、代码实验、数据分析、图表生成、论文写作和自我评估等环节。​​(一)科研协作者类 Agent​代表:SciSciGPT、Google AI co-scientist​强调在人类研究者主导下,AI 作为科研助手或协作者参与具体环节。主要帮助研究者完成文献理解、问题拆解、数据分析、结果解释和研究方案生成。​【SciSciGPT】​论文:SciSciGPT: advancing human–AI collaboration in the science of science​发表期刊 | 年份:Nature Computational Science(2025 年 12 月)​解决的问题:论文认为,现在科研越来越依赖大规模数据和复杂计算方法,但这会带来很高的技术门槛。研究者可能有研究问题,但需要自己完成数据库理解、数据清洗、SQL 查询、代码分析、可视化和结果检查,效率低、门槛高。​常规科研分析流程:文献检索 → 找数据 → 理解数据库结构 → 写 SQL / Python / R → 做统计分析 → 画图 → 检查结果 → 反复修改。​系统架构:5 大智能体协同​1.ResearchManager (总控-拆解任务)​2.LiteratureSpecialist(文献专家)​负责科学学领域文献检索、知识提取、综述生成与引用溯源的专业智能体,核心通过领域专属检索增强生成架构实现精准知识调用,降低大模型幻觉风险。​完整工作流程:​◦根据用户的研究问题,生成规范的检索问题​◦LLM 自动识别并应用元数据过滤条件,可限定仅检索文献的摘要、方法、结果、讨论等特定章节​◦使用 HyDE(假设文档嵌入) 生成多个与问题相关的 “假设段落”​◦用这些假设段落与SciSciCorpus(科学学文献库)中的文本片段进行向量相似度匹配​◦对检索到的内容进行整合、归纳与解读,生成带学术引用的综述性回答​核心功能补充:​◦可根据问题需要,对摘要、方法、结" + }, + { + "group": "dc战略问题研究院", + "sender": "莫润麟", + "time": "2026-05-19 01:10:51", + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/YEAcwAuHkiGwngk4z48cLBzWnth", + "content": "日报-莫润麟输入“/”快速插入内容2026.5.18-日报-莫润麟​用户5855用户58555月18日修改今日内容​①整理导师反馈整改内容汇总​②交叉检验开题报告、PPT 与整改汇总​③AI辅助工具搭建:基于Gemini Gem的DBA开题报告智能评审​一、整理导师反馈整改内容汇总​重点将各项反馈拆解为:​•教授提出了什么问题;​•如何理解该问题;​•对应在 PPT 或文字版开题报告中做了哪些调整;​本次整理重点覆盖:​•七机制主次分层与理论展开;​•公平性、激励性等机制边界澄清;​•互动性、流动性动态分析边界补充;​•两团体模型向多团体场景的承接说明;​•变量构建、机器学习识别与治理输出路径补强。​二、交叉检验开题报告、PPT 与整改汇总​对当前最新版开题报告正文、答辩 PPT 和整改说明材料进行了交叉核对,重点检查三类问题:​1. 教授建议是否真正落实到材料中​•核实七机制展开、游戏案例补充、文献空白、理论与实证分开、治理输出等关键修改,均已在 PPT 中体现。​2. 整体质量审核与阶段性评分​•从DBA 开题标准和三位教授反馈要求两个维度,对当前材料的完整度、逻辑性与说服力进行复核。​•综合判断:当前版本已较好回应核心修改意见,研究问题、理论框架、实证路径与治理落点基本闭合,具备进一步提交审阅的条件。​•阶段性评分:​◦开题报告正文:89–91 分​◦答辩 PPT:88–90 分​◦整改汇总:92–94 分​•当前主要剩余工作,已从“大结构修改”转入细节精修、答辩口径凝练与潜在追问准备。​3. 整改汇总是否准确反映已完成改动​•对照材料后确认,整改说明与当前版本总体一致,能够较完整地展示“导师建议—修改动作—落实结果”的对应关系。​​三、AI辅助工具搭建:基于Gemini Gem的DBA开题报告智能评审​(一)搭建背景与目标​痛点:这几轮开题报告修改下来,院长和两位教授每轮都会提出新的优化方向,涉及问题意识、理论逻辑、方法路径、治理落点、文字表达等多个维度。每次修改后,存在两个实际困难:​1.很难快速自查\"上轮意见是否真正落实了\"​2.不容易全面排查\"还有哪些薄弱环节没被发现\"​想法:把三位教授多轮反馈中逐渐形成的评审标准和修改逻辑,结构化地沉淀成一个AI评审工具,在每次提交前做一次结构化自查,提前发现逻辑断点和表达模糊的地方,减少被打回修改的次数。​🔎核心目" + }, + { + "group": "dc战略问题研究院", + "sender": "陈楚真", + "time": "2026-05-18 23:55:05", + "url": "https://dianchukeji.feishu.cn/docx/SFrYdULAvo9Z1oxVUHvcReOcncW", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "张家振", + "time": "2026-05-17 01:36:07", + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/FFlCweEYqiBlPPkSUzHc1S6bnIc", + "content": "日报-张家振输入“/”快速插入内容2026.5.16-日报-张家振​用户9559用户95595月17日修改工作内容概述​1、参加老李的游戏课​一、游戏课学习要点​(一)设计范式四大关键元素​•土地与空间约束​这是率土-Like最底层的规则基石。玩家的一切行为最终都指向土地。它是唯一资源来源、战力投射的载体,更是赛季终极目标本身。核心铁律只有一条:只能攻占与自己领地相邻的格子。这条简单规则,将整张地图变成巨大的战略棋盘,每一次扩张都必须一寸一寸地“铺路”。空间由此转化为最稀缺的资源,关口、码头、峡谷因之成为必争之地,铺路的方向、速度与路线选择,本身就是一场无声的战争。​•强制联盟​率土-Like从设计上就拒绝了独狼。不加入同盟,永远无法触及赛季的最终胜利——攻占洛阳、夺取霸业所需的兵力规模与资源调度,远超任何个体所能企及。这本质上是一种“强社交”:无论玩家性格如何、偏好何种玩法,只要想体验完整内容,就必须进入集体,进而卷入分工、沟通、信任、背叛、外交这一整套人类社会的经典戏剧。强制联盟,是整个品类社交生态的发动机。​•公平战斗​公平战斗是率土-Like与“数值碾压型”游戏的分水岭。核心主张很明确:战斗结果应由策略决策的质量决定,而非由谁花钱更多、谁入坑更早来决定。数值有影响,但不能是决定性的。从产品演进看,方向清晰而坚定:不断减少纯数字差异,丰富策略维度,拔高博弈价值。《率土之滨》建立了基础的克制与战法框架,《三国志·战略版》在技能设计与阵容搭配上持续深化,《三国谋定天下》则进一步通过战法发动率的稳定化设计、平民“神队”的主动塑造,让“策略正确”比“充值更多”更有分量。​•赛季制​游戏玩久了,头部优势滚雪球般膨胀,后来者翻盘无望;而大部分目标达成后,玩家又会坠入无事可做的空虚。赛季制的答案干脆利落,定期重置赛局,翻盘重来。它进行了精细化的取舍:保留个人资产(武将、战法、装备)与操作经验,重置服务器状态(土地归零、城池易主、同盟洗牌)。这创造出一种独特体验——你比上个赛季更强了,但面对的局面又是全新的。赛季时长决定玩家多久进入疲劳期,也框定了商业化节奏;重置范围在积累感与公平性之间走钢丝;配对机制——下赛季与谁为敌、如何分组——更是决定体验质量的关键变量。《三国谋定天下》缩短赛季节奏,加快了“重开一局”的频率以维持新鲜感,但这也暴露了新问题:若匹配质量不高、长草期填充不" + }, + { + "group": "dc战略问题研究院", + "sender": "夏莲", + "time": "2026-05-17 01:36:02", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/TXNAdSOe2oLdrLxYswZckoR9nUd", + "content": "日报输入“/”快速插入内容2026.05.16-深圳研究部日报​用户2119用户2119用户5855用户58555月17日修改参加《老李的游戏课》36期培训课​深圳研究部参与人员:夏莲、莫润麟、胡辉俊、张家振​本期主题:关于“率土LIKE-SLG产品系列”的分析探讨​​一. 《\"降肝减氪\"引发的系统重构与生态演化》​分享人:广州战略研究部 陈楚真​(一)重点提炼​1.市场破局:降肝减氪的底层框架重构​•率土类SLG的核心痛点是三高门槛:​◦高时间成本(需手动铺路、定闹钟打城)​◦高氪金成本(以《三战》\"孙10万\"锁卡机制为典型)​◦高社交成本(强同步性考核),导致品类长期小众​•三谋的破局路径是将劳动密集型模式重构为策略与社交主导的自立运行模式:​◦减氪:取消锁卡、降低保底、缩短养成周期、压缩付费差距,平民玩家拥有完整参与链路​◦降肝:自动铺路、预约打城、结义托管,将机械性重复操作交给系统,玩家专注决策与社交​2.副作用:长草期结构性问题​•降肝减氪使内容消耗速度指数级加快​◦三谋赛季有效时间从约50天压缩至14天左右,较三战/率土加速3-4倍,玩家有60%时间处于长草期​•赛季无法无限压缩(大小月卡回收周期、社交磨合需求、高CAC向LTV回收压力)​◦使长草期成为商业模型与体验节奏错位的结构性矛盾,并衍生两大问题:​▪游戏沦为签到工具,活跃与付费大幅下滑,运营压力实际转嫁给管理层​▪玩家获得充足时间研究匹配算法、进行跨服外交,长草期成为博弈温床​3.生态危机:匹配机制被攻克与控红现象​•匹配机制以200人战队为单位进行实力配平,初衷是打破阶级固化​•但精准匹配导致激励不相容:世界杯高强度激战与郊区躺平所获霸业奖励相同,理性玩家自然倾向后者。​▪️衍生控红行为​管理层借助外部工具(如\"朋友1号\"小程序)评估账号红度,招募时刻意压低战队评分,精准落入郊区实施降维打击​两支控红联盟郊区相遇后,往往进一步达成种田协议共谋分奖,生态加速走向死寂。直接修改匹配算法打补丁的方式治标不治本,且存在误伤正常玩家的风险。​4.官方治理:冠军服机制​核心逻辑是不禁止控红,而是用更高收益覆盖低效最优解,让玩家理性选择与系统目标对齐​•机制设计​◦服务器内玩家通过战役规模、杀敌数量、推进格数、技能使用效率等多维度积累热力值​◦热力值达标后普通服升格为冠军服,解锁稀有红兵红马拍卖、专属外观、" + }, + { + "group": "dc战略问题研究院", + "sender": "夏莲", + "time": "2026-05-17 01:35:58", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/V9ejdL4QBo6XpZxWxPDcVNRMnNh", + "content": "日报-深圳研究部日报输入“/”快速插入内容2026.05.16-日报-深圳研究部日报​用户4109用户4109用户5855用户58555月17日修改一、工作内容概述​1.针对调整问题进行整改​​二、问题整改​(一)“多人”概念需要前置交代​提出问题:​目前对“多人”的解释不够清晰。需要在论述前段讲清楚多人的具体含义,以及围绕这一主题要解决什么核心问题,并通过文献综述支撑关键问题的提出。​调整说明:已新增并前置“多人社交竞争”的概念界定内容。​已调整内容:​1.新增“概念界定:多人社交竞争游戏​所称“多人游戏”并非简单指人数,而是个体嵌入团体、团体进入赛局、赛局置于竞赛中的多层嵌套竞争结构,因此平台治理的重点不再只是单局胜负,而是持续投入、组织协作与生态稳定。​2.补充“单人 / 简单竞技”与“多人社交竞争”的对比​从核心驱动要素、交互特征、平台角色和管理重点四个方面说明区别。​3.突出本文研究对象的多层嵌套结构​通过结构图展示个体、团体、赛局、竞赛之间的层级关系,说明持续投入不是单一用户行为,而是多层结构共同作用的结果。​75%​25%(二)背景部分关键理论锚点需要更突出​提出问题:​当前开题报告中“从增量到存量经营、平台治理体系构建、机制设计、制度解决”等关键理论锚点存在感偏弱,需要进一步突出。​调整说明:背景部分已重新强化理论锚点的递进表达。​已调整内容:​1.突出“从增量扩张到存量经营”​通过行业数据说明游戏行业用户红利减弱,平台增长重心从新增用户扩张转向现有用户长期参与和深度运营。​2.突出“规则机制”作为平台治理工具​明确说明:投入衰减不是单纯内容吸引力下降,而是规则机制如何影响参与者持续投入的问题。​3.补充文献基础与研究空白​将平台治理、游戏参与、竞赛设计和团队协作等文献作为理论基础,说明现有研究对团体赛季制竞赛中的“规则机制—持续投入”解释仍不足。​4.进一步落到研究问题与治理路径​将研究问题整理为“机制抽象、关键识别、关系解释、异质性治理”四个递进问题,为后续规则优化和治理输出做铺垫。​(三)背景部分需要从具体游戏问题切入​提出问题:​1.虽然结构完整,但游戏行业最有特色、最有画面感的内容没有展示出来。要加入真实游戏截图、玩家动态和业务场景,让理论框架有具体落脚点。​2.建议一开始从企业具体游戏问题切入,先展示并验证问题存在,再用理论机制展开,这样" + }, + { + "group": "dc战略问题研究院", + "sender": "胡辉俊", + "time": "2026-05-16 02:02:49", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/GcKkd0H5EoQY9KxKiSVcZ05VnVc", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "夏莲", + "time": "2026-05-16 02:02:48", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/JfNIdEbJ3o9QLOxlaHzcs7X7nkh", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "莫润麟", + "time": "2026-05-16 02:02:25", + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/FdI2woTLai6GPDkpPqrcFXYZnGh", + "content": "日报-莫润麟输入“/”快速插入内容2026.5.15-日报-莫润麟​用户5855用户58555月16日修改今日内容​①优化调整开题报告内容​②制作PPT​一、优化调整内容​(一)问题三:互动性与流动性的长期动态分析路径需要进一步说明​提出问题:​互动性机制与流动性机制本质上都属于长期动态机制,但当前博弈论推导更多是在刻画机制成立的理论条件与均衡逻辑,容易被理解为用相对静态的模型直接替代长期动态效应本身的识别。​具体而言:​•互动性关注的是团体之间在重复互动中,是否会逐渐形成默契避战、低竞争合作甚至类共谋关系​•流动性关注的是成员迁移、联盟扩张与组织结构固化,是否会在跨期演化中放大强者集聚与结构垄断风险​因此,需要进一步明确:理论推导主要用于说明动态机制何以形成,而互动性与流动性的真实长期影响,仍需结合跨期跟踪、动态数据或规则变化观察进一步分析。​调整说明:​围绕这一建议,已从理论边界说明与后续动态识别路径补充两个方面,对互动性和流动性机制完成优化。​1. 已补充互动性机制的动态分析边界​对应位置:互动性机制——\"理论推导\"结尾​在互动性理论推导结尾新增说明,明确重复博弈模型主要用于刻画:​•低竞争稳态为何形成​•默契避战关系为何可能稳定存在​•平台规则可能通过何种方向进行调节​但团体间竞争互动是否会在真实生态中持续弱化、跨轮次或跨赛季演化、最终形成稳定的默契避战关系,仍属于长期动态过程,不能仅由理论推导直接替代其经验识别。​这一调整进一步厘清了:互动性模型负责解释形成逻辑,长期动态效应仍需在后续经验分析中谨慎识别。​2. 已补充互动性机制的后续动态识别路径​对应位置:互动性机制——\"现实规则映射与经验识别\"部分​在互动性经验识别部分进一步补充,互动性具有明显的跨轮次、跨赛季演化特征,后续可结合以下方向进行持续观察:​•定期跟踪与更长周期数据​•固定对手关系变化​•竞争强度变化趋势​•低竞争合作迹象的识别​同时补充了更具拓展性的识别思路:在业务条件允许时,可进一步考察匹配重组、轮次去重或外部扰动规则变化与互动性状态之间的关系。​该表述回应了教授关于\"定期跟踪\"与\"通过机制变化观察影响\"的建议,但仍保持审慎,不将其写成当前研究必须完成的实验任务。​3. 已补充流动性机制的理论解释边界​对应位置:流动性机制——\"理论推导\"结尾​在流动性理论推导后新增说明,明确当前流动性模" + }, + { + "group": "dc战略问题研究院", + "sender": "张家振", + "time": "2026-05-16 01:51:05", + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/MKv7w5MX5iW54ykkM7Vcfu6YnTg", + "content": "日报-张家振输入“/”快速插入内容2026.5.15-日报-张家振​用户9559用户95595月15日修改工作内容概述​1、学习并实践制作知识库​😄昨日旁听了千山项目组同事关于知识库的分享,收获颇丰。计划借助 Cursor 工具动手开发一款知识库应用,在实践中理解知识库的构建与应用流程。​一、RAG 系统简述​RAG 在知识库中的作用是:将大语言模型与外部知识检索相结合,使知识库从被动存储升级为能够主动理解问题、实时召回相关信息并生成有据可依的精准答案的智能系统。​RAG(Retrieval-Augmented Generation,检索增强生成)是一种让大模型在回答问题前先从外部知识库检索相关信息的架构。其核心流程为:用户提问 → 从知识库检索相关内容 → 将问题和检索结果拼接成 Prompt → 大模型生成答案。​RAG 的核心价值在于解决大模型的两个局限:知识截止日期问题和幻觉问题。通过外挂知识库,模型无需重新训练就能访问最新或私有的知识,且回答有据可查。​二、RAG 系统组成​1.数据摄取层:支持多种格式文档的解析和加载(PDF、Markdown、网页等)。​2.文本切片:将长文档按语义或长度切成小块,保证每块信息完整且便于检索。​3.Embedding 模型:将文本块转换为向量,实现语义级理解。​4.向量知识库:存储和检索 Embedding 向量,支持语义搜索。​5.全文检索引擎:基于关键词匹配的搜索能力,补足向量检索的短板。​6.大语言模型:基于检索结果生成最终回答。​7.编排层:串联检索和生成流程,处理交互逻辑。​(一) Embedding 模型​能将文本、图片等非结构化数据转换成固定长度数字向量(一串数字)的神经网络模型。这个向量可以看作数据的“语义坐标”,意思相近的文本,其向量在数学空间中的距离也接近。​能干什么​1.语义搜索:不依赖关键词字面匹配,用户输入“我想吃水果”能找到“我吃苹果”的笔记。​2.文本聚类与分类:自动将相似内容的笔记归到一起。​3.作为大模型的输入基础:所有大语言模型内部都在使用 Embedding 来理解文字,RAG 中检索出的文本块最终也以此形式参与后续生成。​知识库中的作用​Embedding 模型负责将笔记内容和用户问题转化为向量,存入 Chroma 向量数据库。用户提问时,系统用同一模型将问题向量化,再由 Chro" + }, + { + "group": "dc战略问题研究院", + "sender": "黄静雯", + "time": "2026-05-16 01:44:16", + "url": "https://dianchukeji.feishu.cn/docx/M8TId6mhhooxZJxHVc5cAwwXnJh", + "content": "日报-黄静雯输入“/”快速插入内容2026年5月15日工作日报-黄静雯​用户3579用户35795月16日修改一、工作内容概述​1.参加GGS2026全球游戏峰会​​二、GGS2026全球游戏峰会收获与思考​今天参加GGS2026全球游戏峰会(AI研发&中台专场),涵盖了游戏公司在AI爆发时代下的战略选择、从立项、研发、运营、数据分析迭代等各个方面深度应用AI的实践分享,同时也反映出AI时代下对组织文化、架构、工作流、人才提出了新的要求​(一)总体判断:AI正在改变游戏公司的组织竞争方式​本次几场分享共同指向一个趋势:​AI对游戏公司的影响,不只是个人工具提效,而是在重构游戏公司的产品孵化、研发协作、运营迭代、数据决策和组织知识沉淀方式,头部和腰部游戏公司已经进入重构组织生产系统的阶段​游戏公司的竞争正在从“单个项目组能力”扩展至:​•是否有高频创意验证机制​•是否有AI辅助研发工作流​•是否有统一数据与业务语言​•是否有运营/数据/研发高度协同能力​•是否能把项目经验沉淀成AI可调用资产​•是否能让组织持续学习,而不是每次从零开始​​(二)买量驱动公司更容易吃到AI创意验证红利​冰川网络是一家买量和数据驱动特征很强的游戏公司,和三七类似。它们不是单纯相信创意,而是更相信:​高频测试、数据反馈、快速筛选、放大赢家​冰川网络副总在分享里提到:​1.“好游戏”的定义不是抽象的“艺术表达”或“精品叙事”,而是非常贴近买量模型——吸量、好玩、后端商业化成熟​2.“好游戏”必须吸量、能让玩家玩下去,并且能在游戏内形成消费​3.爆款有概率性,在同样时间和成本下验证更多方向,就可能提高命中机会​他们今年建立了“AI游戏超级个体小组”,核心逻辑是通过AI降低创意验证成本,用更低成本、更高频率验证更多产品机会。过去一个想法要拉程序、策划、美术,可能要2—4周甚至更久,现在可以通过AI快速生成HTML5 Demo,并当天迭代多个版本​​AI对买量型公司当前确实更有利,因为AI强化的是它们原本就擅长的“流量—素材—数据—验证—放大”系统。这不是说AI让创意本身更容易成功,而是AI让失败更便宜,让筛选更快,让潜在赢家更早被发现​•AI降低的是试错成本,不是成功难度​•AI Demo不等于可上线(有商业化能力)产品​•高频生成创意会快速内卷​•长期优势仍然取决于用户理解、产品判断、商业化承接" + }, + { + "group": "dc战略问题研究院", + "sender": "陈楚真", + "time": "2026-05-16 01:42:02", + "url": "https://dianchukeji.feishu.cn/docx/SPnWddkXkoY8GaxIUyocufXBngh", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "黄静雯", + "time": "2026-05-15 09:02:29", + "url": "https://dianchukeji.feishu.cn/docx/SOaBdskVhoSXo0x6gvbcLnKHntb", + "content": "日报-黄静雯输入“/”快速插入内容2026年5月14日工作日报-黄静雯​用户3579用户35795月15日修改一、工作内容概述​1.《三国:谋定天下》、《三国:天下归心》、《三国:冰河时代》、《我的花园世界》体验​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 类推演判断非客观事实​​•点击查看详情:​◦《三国:谋定天下》演武大会 P0 知识资产案例​◦战略研究部 AI 研究工作流总览​🤔AI 研究工作流建设不能只" + }, + { + "group": "dc战略问题研究院", + "sender": "胡辉俊", + "time": "2026-05-15 01:46:08", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/BbYMdLdBzoVunRxj51ZcP7gxnFd", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "莫润麟", + "time": "2026-05-15 01:45:54", + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/LxmkwF7MRiUJInk3V6Mcn5Xanfu", + "content": "日报-莫润麟输入“/”快速插入内容2026.5.14-日报-莫润麟​用户5855用户58555月15日修改今日内容​①根据新一轮优化建议进行调整​②参加AI分享会​一、优化调整内容​(一)问题一:公平性与激励性机制边界需要进一步厘清​提出问题:​在七机制框架中对公平性与激励性分别进行了理论建构,但二者在表达和指标选择上存在一定的相近性。​具体而言:​•公平性机制主要通过赛局内团体能力差异、离散程度等指标进行刻画;​•激励性机制中使用奖励分布基尼系数G表征奖励结构集中程度,也带有“差异分布”的含义。​因此,需要进一步讲清:公平性与激励性究竟分别解释什么问题,二者是否存在概念或指标层面的重叠。​🔎调整说明:​当前已从机制界定、边界说明和指标解释三个层面完成优化,进一步明确:公平性关注竞争结构,激励性关注奖励回报结构。​1.已优化激励性机制的界定表述​对应位置:博弈论推导部分——“基于激励性的机制探讨:奖励梯度驱动”之“机制界定”​原文中“竞赛奖励首先是一个分配问题”的表述,容易使激励性与公平性产生“分配差异”层面的联想。​现已调整为:​激励性并不关注奖励是否平均分配,而关注不同名次之间的回报梯度如何设置,以及奖励梯度能否持续驱动参与者追加投入。​通过这一调整,激励性的核心问题进一步明确为:​奖励结构如何形成持续竞争刺激。​2.已补充公平性与激励性的边界区分​对应位置:激励性机制界定部分​在激励性机制正式展开后,新增了对二者边界的专门说明:​•公平性关注的是:​赛局形成时,竞争对象之间的能力差异是否过大,参与者是否处于一个仍具有可竞争性的比较空间。​•激励性关注的是:​在竞争已经成立的前提下,奖励梯度与回报差异能否继续强化参与者的投入动机。​由此进一步明确:​公平性作用于竞争结构,激励性作用于回报结构;前者回答“竞争空间是否值得进入”,后者回答“进入竞争后是否仍值得持续投入”。​3.已澄清奖励分布基尼系数G的指标含义​对应位置:激励性机制理论推导部分​针对“基尼系数是否会被理解为公平性指标”的疑问,现已在正文中补充说明:​本文使用奖励分布基尼系数 G,并非用于判断赛局竞争是否公平,而是用于刻画奖励梯度的集中程度,即奖励结构是过于平缓、适度分层,还是过度向头部集中。​这一修改使基尼系数G的机制归属更加清晰:​•公平性指标:刻画赛局内竞争能力差异;​•激励性指标:刻画奖励回报" + }, + { + "group": "dc战略问题研究院", + "sender": "张家振", + "time": "2026-05-15 01:45:53", + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/HkYPwjIpBiQFeVknIqac7pk4n0e", + "content": "日报-张家振输入“/”快速插入内容2026.5.14-日报-张家振​用户9559用户95595月15日修改工作内容概述​1、学习分析Claude Code、Hermes Agent、OpenClaw这个AI Agent机制实现的差异​一、上下文管理​1.Claude Code​◦会话内:围绕当前任务串成一条主线,工具调用结果按时间顺序往里接;快把上下文窗口占满时,会自动压缩整理,并留下能看懂的检查点。遇到子任务会开并行时间线去跑,不让探索过程的细枝末节冲乱主线。权限判断这类旁路工作,会单独用一份裁剪过的对话片段来做,不和主上下文搅在一起。​◦会话外:没有统一的记忆模块,长期需要记住的东西,就靠仓库里常规的 Markdown 和文档,由人或 Agent 自行维护。好处是灵活、和工程目录融为一体,缺点也很明显:膨胀了没人管,得靠 Git 评审这类手段来兜底。​2.Hermes Agent​◦会话内:按聊天时间线自然推进,内置用量感知,一旦超过比例阈值就触发压缩。压缩时会刻意保留开头几条和末尾几条,中间部分做收束;很早之前的工具长输出,通常被替换成一句简短说明,腾出空间但不假装那部分内容还在。​◦会话外:在固定位置维护两份 Markdown 笔记——一份记“事实记忆”,一份记“用户偏好”。条目之间用固定分隔符分段管理,像一张张小卡片,方便追加、替换或删除某一条,不用整篇重写。两份文件都有明确的字符上限,超了就直接拒绝写入,逼着模型先精简再存。写入前还会做安全扫描,防止注入或不可见字符混进去。每次会话开始时,会把这些磁盘内容读进来形成一个快照,同一会话中途新写入的记忆,不一定立刻反映到当前对话里,得新开一次会话才会稳定对齐。此外还配有 SQLite 加全文检索,专门用来搜历史会话,和那两份日记是两个独立层次。​3.OpenClaw​◦会话内:照常维护当前通道的对话时间线,同时在后台按分钟级周期做整理,把短期积攒的候选记忆排序、晋升或清扫掉,不让整理动作卡在用户每句话的响应上。像心跳检测、后台唤醒这类维护任务,会单独用一个独立会话身份去跑,完全不会搅乱主对话的上下文。​◦会话外:把 MEMORY.md 当成工作区的核心记忆文件来对待,和插件状态联动管理;另外还会维护一份 USER.md 用户档案。需要更强记忆能力时,可以接入向量库,实现自动捕获和按需召回,精准补充到上下文里。" + }, + { + "group": "dc战略问题研究院", + "sender": "夏莲", + "time": "2026-05-15 01:45:47", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/HnNgdyIxso9WWYxCCPLcktDTnLh", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "陈楚真", + "time": "2026-05-15 00:36:28", + "url": "https://dianchukeji.feishu.cn/docx/V9fzdn7fZoTSaGxX7yhcwTQUnFc", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "黄静雯", + "time": "2026-05-14 09:29:52", + "url": "https://dianchukeji.feishu.cn/docx/GuJRdtHTKoQ8QaxVbGecxhuDn5Q", + "content": "日报-黄静雯输入“/”快速插入内容2026年5月13日工作日报-黄静雯​用户3579用户35795月14日修改一、工作内容概述​1.《三国:谋定天下》、《三国:天下归心》、《三国:冰河时代》体验​2.《我的花园世界》体验​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 链路,将其进一步整理" + }, + { + "group": "dc战略问题研究院", + "sender": "张家振", + "time": "2026-05-14 02:01:40", + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/ZgePwV6s4iMUL0kYiwjcr8ZWnIy", + "content": "日报-张家振输入“/”快速插入内容2026.5.13-日报-张家振​用户9559用户95595月14日修改工作内容概述​1、继续整理之前学习整理的Agent​一、提示词分层​将原本混杂在一起的提示系统拆解为三层独立落盘、互不耦合的规则集:​•工程层(仓库级):承载当前代码仓库所需的协作约定,包括项目规范、工具调用协议、领域术语和流程约束,跟随仓库进行版本控制。​•用户层(个人跨项目):沉淀个人稳定的使用偏好,例如角色设定、输出风格、常用工作流和底线要求,一份维护,在所有仓库中复用。​•全局层(产品通用契约):定义产品全域必须遵守的基线规则,比如安全红线、敏感数据处理策略、输出格式强约束,作为最低限度的兜底保障。​每次会话启动前,不再从混杂的文本中临时拼凑指令,而是按预定的优先级和结构,把记忆、画像、用户片段、项目片段组装成一条边界清晰、无冲突的上下文,注入系统指令。三层各自拥有独立的存储位置和加载开关,变更互不影响。​(一)为什么要这样做​原来的做法是将所有规则全部写入同一个配置文件。这会直接引发四个问题:​•项目切换成本高:个人偏好与项目规则深度交织,更换仓库时必须手工剥离,很容易残留无关设定。​•版本审查不可行:工程变更与个人偏好混在一起,进行 PR 审查时无法区分修改来源,也难以判断影响的边界。​•上下文窗口浪费:大量对当前任务无用的信息被重复加载,挤占模型的注意力资源,同时多条矛盾指令并存,会降低输出的一致性和准确率。​•长期维护困难:任何一处微调都需要在大量文本中定位,容易产生意外覆盖,导致维护人员不敢轻易改动。​根本原因在于缺乏分层隔离,使得不同生命周期、不同责任主体的规则强行糅合,复用性、可审查性和可控性全部受损。​(二)思路​核心思路是把提示当成一种需要架构设计的资产,而不是一段随意粘贴的文本。​首先,三层对应三种完全不同的变更频率和负责主体。工程层由项目维护者在仓库内直接管理,可以走标准的 Code Review 流程;用户层属于个人配置,应当独立于项目存在,更换仓库时自动挂载;全局层代表产品安全底线,必须集中管控,不能被局部修改轻易覆盖。这种切分天然解决了权限管理和发布流程的问题。​其次,每次会话将分散的记忆和画像进行打包注入,是为了构建一条稳定且可预测的上下文基线。通过规定明确的拼接顺序和覆盖规则,即使来源多样,最终生成的指令也是确定性的,避免" + }, + { + "group": "dc战略问题研究院", + "sender": "莫润麟", + "time": "2026-05-14 02:01:27", + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/EfDVwSBQIipcL1kG21TcP1ZinKf", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "胡辉俊", + "time": "2026-05-14 02:01:15", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/BRyrdjvPboqbX2xjQb4cZnBqnde", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "夏莲", + "time": "2026-05-14 02:01:02", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/GaBtddjSqoukwVxGYavcp31zn0e", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "陈楚真", + "time": "2026-05-14 01:22:31", + "url": "https://dianchukeji.feishu.cn/docx/Eie1dKsSpoYQkjxUlvdcc5Yknff", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "陈楚真", + "time": "2026-05-13 10:08:50", + "url": "https://dianchukeji.feishu.cn/docx/AhYwdapYjo9Elkx2giXczIK2nno", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "黄静雯", + "time": "2026-05-13 02:58:37", + "url": "https://dianchukeji.feishu.cn/docx/ExYndBzwSoEobXxqgiicDkionnh", + "content": "日报-黄静雯输入“/”快速插入内容2026年5月12日工作日报-黄静雯​用户3579用户35795月13日修改一、工作内容概述​1.《三国:谋定天下》、《三国:天下归心》、《三国:冰河时代》体验​2.《我的花园世界》体验​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:可将文档同步为本地 Markdo" + }, + { + "group": "dc战略问题研究院", + "sender": "莫润麟", + "time": "2026-05-13 01:32:57", + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/BVdywLGYyiZFTXkS2nWcHoQ6nmf", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "胡辉俊", + "time": "2026-05-13 01:29:02", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/RKktdFgpDovfSJxcDJpcjbbEnHg", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "张家振", + "time": "2026-05-13 01:28:58", + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/W0bjwALE3i2EfSkUxIZcXxtTnAb", + "content": "日报-张家振输入“/”快速插入内容2026.5.12-日报-张家振​用户9559用户95595月13日修改工作内容概述​1、继续整理之前学习整理的Agent​一、Agent Team(智能多角色协作)​将复杂任务按“先谁做、再谁做”的流程拆分为多个阶段,系统按顺序调度不同“角色”各负责一段,最终串联合成完整结果。适合研究+落地、多步骤流水线等需要不同专长串联的场景。​•每个阶段使用贴合任务的指令约束模型,避免“一把抓”导致的步骤遗漏或风格混乱。​•上一阶段的输出作为下一阶段的输入,逻辑链路更清晰。​•对使用者而言仍是一次提问,中间角色协作由系统自动编排。​•主会话中先判定是否需要组队及分组方式,通过后由内部调度器按成员列表依次执行,然后主agent进行最终的统一汇总。​二、Sub Agent(子代理)​在主对话外单独拉起一条干净上下文执行小型专项任务,完成后将结构化结果返回给主 Agent,主Agent上下文不会被中间长过程所影响。​•用于隔离子任务、控制步数与输出长度,避免主会话中的工具调用和中间草稿弄乱上下文。​•主对话保持清爽;子任务失败或跑偏时影响范围易于收敛,适合探路、专项小活。​•通过工具触发:以独立配置副本启动临时 Agent,执行完毕后将文本结果交回主流程。​三、TUI(终端里的聊天界面)​在命令行中打开全屏终端界面进行对话,替代逐行滚动的日志式交互。​•针对长对话优化区域布局与滚动,对长回复和表格类内容做了展示适配。​•本地、轻量、不依赖浏览器,在服务器或 SSH 环境下也能舒适查看对话与模型输出。​•基于终端 UI 库实现布局与渲染,专门处理 Markdown 表格、换行及显示宽度,有效改善字符拥挤、表格竖线对不齐等问题。​😅Agent Team 和 Sub Agent 的目的,都是为了让主 Agent 的上下文保持清爽,降低上下文压缩频率,减少关键信息丢失的风险。Agent Team 还能并行调度互不依赖的子任务,缩短响应时间。​但TUI 这边有个问题:为了让等待不那么焦虑,界面上会显示当前正在做什么,但输出内容一多,界面就乱了,这个还需要在调整下。​" + }, + { + "group": "dc战略问题研究院", + "sender": "夏莲", + "time": "2026-05-13 01:28:44", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/Kv25dB4ecoMey9xrTZ6cr3REnbc", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "张家振", + "time": "2026-05-12 01:13:54", + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/XneKwLxUmilaOmkJh8fcRPMInOe", + "content": "日报-张家振输入“/”快速插入内容2026.5.11-日报-张家振​用户9559用户95595月12日修改工作内容概述​1、继续整理之前学习整理的Agent​一、上下文管理​我认为Agent 工程里最难的一块是上下文管理:要同时兼顾系统 Prompt、技能与工具说明、多轮对话、工具/技能返回内容,以及会后的技能提炼与生成(如 GEPA 等)。任一环节过长,都会挤压真正用于推理的有效窗口。​网页类工具与体积​典型例子是一次请求拉回整页 HTML:其中 JS、CSS、标签与正文很容易把中小模型的上下文占满。当前做法是尽量不走裸 curl 拉全页,改为通过 Jina、Serper 等 API 做抽取或检索型结果,控制进入对话的文本量;后续如有更合适的本地裁剪/抽取方案,再评估替换或补充。​工具执行结果与模型行为​技能/工具执行在框架侧会区分ok/error/missing。失败时仍会把对应tool消息(含错误说明,如未注册或异常信息)写入会话,便于模型在后续轮次中意识到调用失败,从而自查参数、工具名是否存在、是否需换技能或重试;不会在失败瞬间静默丢弃,是否从上下文中移除可由策略或模型使用通过移除工具记录的方式处理。​上下文压缩(个人期望形态)​当上下文接近预设上限时,希望采用稳定结构:系统侧 Prompts 始终固定在序列最前;中间对历史里相对不重要的对话与工具长文做一次摘要压缩,剔除噪声、保留任务主线与关键结论;摘要之后再继续按正常方式追加新的用户消息与模型回复,保证核心指令 + 压缩后的历史要点 + 最新进展可读、可续聊。​二、SkillCurator(技能策展/技能仓库整理)​Curator 为会话结束后自动跑的一位技能整理员:专门看这一轮对话里做了什么、模型答了什么,再结合当前项目里已有的技能列表,判断要不要动手改一改技能材料。​能干什么:​•优化技能里的描述类内容(例如说明文字、怎么调用更合适、示例是否好懂),让后面的对话更容易选对技能、少踩坑。​•必要时补一点说明性小文档(仍限于技能目录内、偏说明与维护,不代替主助手去完成用户任务)。​与GEPA的区别​•GEPA:这轮对话值不值得动代码或整份技能;只有它认为该创建/升级时才会跑,不会专门为了只改两句说明而轻量跑一趟。​•Curator:不动或少动逻辑,专门给技能补说明书、润描述,更轻、更专。​技能描述文件​技" + }, + { + "group": "dc战略问题研究院", + "sender": "胡辉俊", + "time": "2026-05-12 01:11:02", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/Kxkpd6g4Fouc57xQqDucSRQznPe", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "莫润麟", + "time": "2026-05-12 01:10:56", + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/MgDbwesIkiw7dHkK9YFc3G4Jn8d", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "夏莲", + "time": "2026-05-12 01:10:47", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/OEOqdSIqFoAWvFxuI2gcz9K4ndc", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "黄静雯", + "time": "2026-05-12 00:57:55", + "url": "https://dianchukeji.feishu.cn/docx/N6J5duouUo2ip7xlyBdcJbkYnxg", + "content": "日报-黄静雯输入“/”快速插入内容2026年5月11日工作日报-黄静雯​用户3579用户35795月12日修改一、工作内容概述​1.《三国:谋定天下》、《三国:天下归心》、《三国:冰河时代》体验​2.《我的花园世界》体验​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:厦门点触科技" + }, + { + "group": "dc战略问题研究院", + "sender": "黄静雯", + "time": "2026-05-10 03:33:49", + "url": "https://dianchukeji.feishu.cn/docx/Me8ed6Rfso05rDxG0yBcDfU5n17", + "content": "日报-黄静雯输入“/”快速插入内容2026年5月9日工作日报-黄静雯​用户3579用户35795月10日修改一、工作内容概述​1.《三国:谋定天下》、《三国:天下归心》、《三国:冰河时代》体验​2.《我的花园世界》体验​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​《我的花园世界》这一轮已经形成较完整的可复用链路,后续可以" + }, + { + "group": "dc战略问题研究院", + "sender": "陈楚真", + "time": "2026-05-10 02:48:38", + "url": "https://dianchukeji.feishu.cn/docx/TLAxdvBokob4xlxlLnHc7VXqnFb", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "张家振", + "time": "2026-05-10 02:00:58", + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/LqVQwLuFLiQdamkOchPczt7dnVh", + "content": "日报-张家振输入“/”快速插入内容2026.5.9-日报-张家振​用户9559用户95595月29日修改工作内容概述​1、通过ollama在GUP服务器上gemma-4-E4B 模型​2、通过UI-TARS自动跑游戏​一、UI-TARS:​UI-TARS Desktop 是由字节跳动开源的一款桌面AI智能体应用,它能让用户通过自然语言来直接控制电脑完成各种操作。​核心功能亮点​•纯视觉驱动:与传统依赖固定控件ID的自动化工具不同,它像人一样通过视觉识别界面元素,即使界面布局发生改变也能自适应。​•自然语言交互:无需学习任何代码或脚本,你只需直接说出或输入你的需求,例如“帮我把桌面整理一下”。​•强大的多模态理解:不仅能识别文字和按钮,还能理解元素间的上下文和空间关系。​•实时动态交互:能实时监控并响应屏幕的动态变化,例如弹窗的突然出现。​•本地运行与跨平台:支持在 Windows 和 macOS 上本地执行任务,保障数据隐私,并通过统一的动作空间在不同应用间无缝切换。​•全面环境整合:除了基本的桌面操作,还能与浏览器、命令行终端和文件系统深度交互。​开源地址:UI-TARS-desktop​😅本地跑不动带图像识别的模型,先是使用的Qwen的模型API,但是他三四秒才反应一次,UI-TARS的好处是可以直接操作我的电脑,比如模拟键盘WSAD跟鼠标点击事件,这样只要电脑能跑的游戏他就能操作。​他能顺利的跑起来了,但是需要好久才跑进下一关。这样太慢也太烧Token了,再试试通过GPU服务器跑模型。​​😅首先我使用的是Ollama来跑本地模型,但是遇到一个问题,Ollama不支持Gemma 4最新的mmproj(视觉投影),这个要等后面Ollama后期兼容。后面换成那llama-server来跑Gemma模型,能成功跑起来了,反应也比Qwen模型反应快了不少,大概一两秒就有一次反馈了,但我使用的是Gemma 4 7B参数的模型,整体感觉没有使用Qwen那么的聪明,后期看看有没有其他更适用的模型或者通过微调的手段,既能保证速度也能保证质量。​" + }, + { + "group": "dc战略问题研究院", + "sender": "胡辉俊", + "time": "2026-05-10 01:54:14", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/FA0FdvarioMIgBx9Swjc4AhWnQe", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "夏莲", + "time": "2026-05-10 01:54:05", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/HAt8dakuAox8SQxgZdecY07wnzg", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "莫润麟", + "time": "2026-05-10 01:53:59", + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/F0D7wBPASiKt6okdbQWcLGdYnIO", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "黄静雯", + "time": "2026-05-09 03:31:23", + "url": "https://dianchukeji.feishu.cn/docx/UNLydXXQNoGXUCxejlXczf5CnVh", + "content": "日报-黄静雯输入“/”快速插入内容2026年5月8日工作日报-黄静雯​用户3579用户35795月9日修改一、工作内容概述​1.《三国:谋定天下》、《三国:天下归心》、《三国:冰河时代》体验​2.《我的花园世界》新号体验(微信小游戏)​​二、《我的花园世界》新号首日体验​此前个人对《我的花园世界》的体验较浅,主要针对GVG相关的公会系统及公会竞赛进行了机制分析​2026年3月27日工作日报-黄静雯,今日起补充完整体验​(一)首日体验进度​(二)首日体验观察点​1.新手教学期设计比同类产品更长、更密集​•主线任务中包含大量非累计式任务,截止主线任务84仍存在大量核心玩法循环相关非累计式任务,适配《我的花园世界》的核心用户(25-45岁女性、宝妈、小游戏轻度用户)​•这类大量非累计式任务虽然会制造重复感和资源消耗压力,但在新手期承担了很强的行为教育功能​◦理解基础循环:不能只把种花、收花、订单当成点击操作,而要理解它们之间的资源关系​◦从“完成任务”转向“管理任务”:看到任务 → 判断资源是否够 → 判断订单是否该交 → 判断花是否该留 → 判断是否需要去好友家补资源。让玩家逐渐意识到:订单不是有就交,资源不是有就用,成熟花也不是有就收​◦培养库存管理意识:资源的价值不是固定的,取决于当前任务链及订单需求​核心玩法循环的关键资源约束:​▪水滴:播种后需浇一次水,水滴每2分钟恢复1点,上限65点(平均每2小时需上线游戏)​▪鲜花培育材料:药剂+肥料+土壤+能量瓶,材料商店随机刷新,急需时可用元宝购买​▪花坊币:极稀缺,仅通过订单获取(1单1-3个),用于解锁新花种​◦为公会系统及公会竞赛做前置训练:前期大量非累计任务,不只是为了主线教学,更是在为后续公会竞赛的任务制、贡献制、资源调度做认知铺垫​▪种植节奏:什么花何时种、何时收、何时留​▪订单消耗:订单不是无脑交,要考虑后续任务​▪资源缺口:水、金币、花、材料都会卡节奏​▪好友补位:好友不是社交装饰,而是资源来源​▪任务驱动:后续公会竞赛也是任务驱动型玩法​强化理解为什么公会任务不能乱接、为什么任务资源要协调、为什么会长会管理任务归属​​2.社交引入及压力梯度​完成主线任务29可解锁好友系统,每日任务里有摘取好友40朵花的要求引导玩家加好友。公会系统需要完成主线任务115才解锁(预估时间2-3天)​•防止竞赛难民:公会竞赛" + }, + { + "group": "dc战略问题研究院", + "sender": "陈楚真", + "time": "2026-05-09 01:14:10", + "url": "https://dianchukeji.feishu.cn/docx/UHHWdXKNiowKsExi7hlc4t8rnmb", + "content": "" + }, + { + "group": "dc战略问题研究院", + "sender": "张家振", + "time": "2026-05-09 01:00:48", + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/YELvw8sX7iQZGlkZXZRc6iGWnLF", + "content": "日报-张家振输入“/”快速插入内容2026.5.8-日报-张家振​用户9559用户95595月9日修改工作内容概述​1、学习LoRA进行模型微调​🧐今天看到Google为Gemma 4推出多 Token 预测 (Multi-Token Prediction, MTP) 草稿器,能将推理Gemma 4速度提升两到三倍。谷歌已经有了Gemini这样的大模型,为什么还要为Gemma 4下这么大功夫。我的想法是小模型的核心价值正在于“可深度定制”。Gemma这类开源基座,真正的作用是被开发者拿去二次蒸馏或微调,打磨成适配自身垂直业务的专属模型,而MTP这类加速技术则让业务落地时响应更快、成本更低——从Gemini浓缩到Gemma,再从Gemma蒸馏出细分场景的专家。​一、LoRA技术​LoRA 是一种轻量级的大模型微调技术,核心思想是在原始预训练权重旁边附加低秩矩阵,仅训练这些小参数,而不动原始模型。​(一)工作原理​•模型全量微调时,需要更新全部权重矩阵,显存和计算开销极大。​•LoRA 的把戏:权重更新量用两个小矩阵和的乘积来近似,即,其中 A,BA,B都是低秩矩阵,参数量远小于原始。​•前向计算变为:。训练时冻结,只更新和。​(二)能干什么​•极低成本微调大模型: 在单个消费级显卡上就能微调 7B、13B 甚至更大的模型。​•多任务快速切换: 不同任务只需保存和加载不同的 LoRA 权重文件(通常几 MB 到几十 MB),无需为每个任务存一份完整模型。​•领域适配与个性化: 用少量领域数据即可让通用大模型变成“行业专家”,如医疗问答、法律文书、游戏 NPC 人格化等。​•保护原模型能力: 不破坏基座模型的通用知识,可随时插拔,几乎无灾难性遗忘风险。​•结合知识蒸馏: 可与“大模型教小模型”流程天然配合,让小模型在特定任务上以极小代价继承大模型能力。​二、结合知识蒸馏的好处​1.一个通用大模型,复制出多个专用小模型​用大模型针对不同任务分别生成训练数据,教出客服小模型、摘要小模型、编程小模型等。每个小模型只做一件事,效果更稳、更好调优。​2.降低对高端硬件的依赖​不是所有场景都适合配备昂贵的服务器集群,小模型让算力有限的环境也能用上好用的 AI。​3.成本大幅降低​大模型跑一次需要的显卡和时间远多于小模型。同样的服务,换小模型能让服务器开销降到几十分之一。如果拿API来" + }, + { + "group": "dc战略问题研究院", + "sender": "夏莲", + "time": "2026-05-09 01:00:31", + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/CmznwoDzIi2nLlkCBxTcyd4nnhe", + "content": "" + } + ] +} \ No newline at end of file diff --git a/data/links/all_feishu_links.json b/data/links/all_feishu_links.json new file mode 100644 index 0000000..f6c773b --- /dev/null +++ b/data/links/all_feishu_links.json @@ -0,0 +1,684 @@ +{ + "links": [ + { + "time": "2026-06-02 03:15:57", + "url": "https://dianchukeji.feishu.cn/wiki/FYKlwX7D5ibbmSkaVMucgKAWnOe", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-06-01 22:44:23", + "url": "https://dianchukeji.feishu.cn/wiki/PY6mwULmXiWbhEkpO3wcYjPCnrh", + "group": "创新组", + "sender": "刘鹏" + }, + { + "time": "2026-06-01 22:44:11", + "url": "https://dianchukeji.feishu.cn/wiki/PuiOw5HETi9pnekp6wlctOIvn0c", + "group": "创新组", + "sender": "韦译" + }, + { + "time": "2026-05-29 23:22:06", + "url": "https://dianchukeji.feishu.cn/wiki/EIWNwKjnIipmStkzIr1cd1kTnPf", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-29 21:27:07", + "url": "https://dianchukeji.feishu.cn/wiki/G5cPwiVSUiGzkrk2ZIzcP24hn0b", + "group": "创新组", + "sender": "刘鹏" + }, + { + "time": "2026-05-29 21:01:23", + "url": "https://dianchukeji.feishu.cn/wiki/N4MdwTuQAiPyGRkHWJPcuyeInpf", + "group": "创新组", + "sender": "韦译" + }, + { + "time": "2026-05-29 00:09:28", + "url": "https://dianchukeji.feishu.cn/wiki/BGn2w5h1Vi8LVWkSzwbcp4xKnNf", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-28 22:39:42", + "url": "https://dianchukeji.feishu.cn/wiki/FVJ6w0RZFirH9tk7uA4ctqQTn1d", + "group": "创新组", + "sender": "韦译" + }, + { + "time": "2026-05-28 22:30:28", + "url": "https://dianchukeji.feishu.cn/wiki/HVxhwFfM2idMx7kTiuBcgVBXnCb", + "group": "创新组", + "sender": "刘鹏" + }, + { + "time": "2026-05-28 01:20:32", + "url": "https://dianchukeji.feishu.cn/wiki/Hv4uwS6U9iqN1skMIKIczOgAnKb", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-27 22:05:15", + "url": "https://dianchukeji.feishu.cn/wiki/Qn6Cw8OgmiBohUkweYCcPnLpnLb", + "group": "创新组", + "sender": "刘鹏" + }, + { + "time": "2026-05-27 22:01:25", + "url": "https://dianchukeji.feishu.cn/wiki/Xd60wq12vi5tAUkx1NmcZdE4nrc", + "group": "创新组", + "sender": "韦译" + }, + { + "time": "2026-05-27 00:30:53", + "url": "https://dianchukeji.feishu.cn/wiki/Y42iwXAsXigSyfkF6bXc5UkLnyb", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-26 22:30:51", + "url": "https://dianchukeji.feishu.cn/wiki/CDoOwO5ppif43Ak6Lx9cWGMensf", + "group": "创新组", + "sender": "刘鹏" + }, + { + "time": "2026-05-26 22:09:01", + "url": "https://dianchukeji.feishu.cn/wiki/SuymwQjFYimgnRkZRePcIW0PnWe", + "group": "创新组", + "sender": "韦译" + }, + { + "time": "2026-05-26 00:17:36", + "url": "https://dianchukeji.feishu.cn/wiki/Mx4SwTP4HiQNISkrygQcGk9jnIe", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-25 22:30:17", + "url": "https://dianchukeji.feishu.cn/wiki/HuUIwA39fi3UsqkdfhTcE9hRnde", + "group": "创新组", + "sender": "韦译" + }, + { + "time": "2026-05-25 22:29:38", + "url": "https://dianchukeji.feishu.cn/wiki/KoXGwnkJaiO7q8kah6WcAGmvn0l", + "group": "创新组", + "sender": "刘鹏" + }, + { + "time": "2026-05-23 00:57:23", + "url": "https://dianchukeji.feishu.cn/wiki/Bf4mwuFU9in51RksjDDc5Fdgnag", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-22 22:39:12", + "url": "https://dianchukeji.feishu.cn/wiki/DcOkwuOj6iPvdWkaFD1clKuRnAB", + "group": "创新组", + "sender": "韦译" + }, + { + "time": "2026-05-22 22:29:44", + "url": "https://dianchukeji.feishu.cn/wiki/VCZAwd24fiQIHdk9nrdcKR9TnWg", + "group": "创新组", + "sender": "刘鹏" + }, + { + "time": "2026-05-22 19:22:14", + "url": "https://dianchukeji.feishu.cn/wiki/RIhawaIYwiBGHak7YAVcaSapnTe", + "group": "创新组", + "sender": "徐锐" + }, + { + "time": "2026-05-22 11:00:22", + "url": "https://dianchukeji.feishu.cn/wiki/SmxzwvhHOi0rk1kSXxmcMobGnGd", + "group": "创新组", + "sender": "徐锐" + }, + { + "time": "2026-05-22 10:59:53", + "url": "https://dianchukeji.feishu.cn/wiki/MObLwsaWoirykyke8NXcFUlhnfd", + "group": "创新组", + "sender": "刘鹏" + }, + { + "time": "2026-05-22 10:57:59", + "url": "https://dianchukeji.feishu.cn/wiki/YniYwtxAiiKqcmkmVM5clNxTnQf", + "group": "创新组", + "sender": "韦译" + }, + { + "time": "2026-05-22 00:21:29", + "url": "https://dianchukeji.feishu.cn/wiki/ZVOVw5BCriBcUfkT1cFcOw3nnBc", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-21 23:13:47", + "url": "https://dianchukeji.feishu.cn/wiki/AjK2wPpI7iOFo5kOImVcEe1WnNS", + "group": "创新组", + "sender": "韦译" + }, + { + "time": "2026-05-21 22:35:51", + "url": "https://dianchukeji.feishu.cn/wiki/F05nwzkQ0ioUxRkNaV8cEBvzn6b", + "group": "创新组", + "sender": "刘鹏" + }, + { + "time": "2026-05-21 21:57:45", + "url": "https://dianchukeji.feishu.cn/wiki/Qad6w4jY9iweK5kggeCcLkifnIN", + "group": "创新组", + "sender": "徐锐" + }, + { + "time": "2026-05-21 01:13:40", + "url": "https://dianchukeji.feishu.cn/wiki/JY56wsBHniMVP6k7y7scQ4gUnOg", + "group": "创新组", + "sender": "韦译" + }, + { + "time": "2026-05-21 01:06:56", + "url": "https://dianchukeji.feishu.cn/wiki/FMV0w4C8ai0oJXkxzhFcygeqnQB", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-20 21:45:20", + "url": "https://dianchukeji.feishu.cn/wiki/IM5zwpPKUixJBUkninjccrl0njg", + "group": "创新组", + "sender": "刘鹏" + }, + { + "time": "2026-05-20 19:41:35", + "url": "https://dianchukeji.feishu.cn/wiki/AqzvwhCH9iKYfbkQ5iacMuKJnMe", + "group": "创新组", + "sender": "徐锐" + }, + { + "time": "2026-05-20 04:22:08", + "url": "https://dianchukeji.feishu.cn/wiki/XRMpwLyT6i55YykYcZScuyRWnyh", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-20 01:28:09", + "url": "https://dianchukeji.feishu.cn/wiki/ZdTPwDH8NiSh09kOuHicQvLSnZd", + "group": "创新组", + "sender": "卓泽" + }, + { + "time": "2026-05-19 20:41:01", + "url": "https://dianchukeji.feishu.cn/wiki/KGMJwIMWOiMnnVk2wyrc0OaRnkh", + "group": "创新组", + "sender": "韦译" + }, + { + "time": "2026-05-19 20:38:21", + "url": "https://dianchukeji.feishu.cn/wiki/DTPlwRI46iKAgfkKvozcBHF1n7c", + "group": "创新组", + "sender": "刘鹏" + }, + { + "time": "2026-05-19 20:12:20", + "url": "https://dianchukeji.feishu.cn/wiki/OY6KwrH1Rifryrk80nSc4aRPnig", + "group": "创新组", + "sender": "徐锐" + }, + { + "time": "2026-05-19 02:10:37", + "url": "https://dianchukeji.feishu.cn/wiki/WiBfwLPy1iBhk5kHfQPccx2un0f", + "group": "创新组", + "sender": "卓泽" + }, + { + "time": "2026-05-18 20:58:05", + "url": "https://dianchukeji.feishu.cn/wiki/PXVywSG2bisQxskF9i1cQSqGndb", + "group": "创新组", + "sender": "韦译" + }, + { + "time": "2026-05-18 20:03:00", + "url": "https://dianchukeji.feishu.cn/wiki/ZCzDwSm2Mi8cJJkIeHucbbcun54", + "group": "创新组", + "sender": "刘鹏" + }, + { + "time": "2026-05-18 18:59:00", + "url": "https://dianchukeji.feishu.cn/wiki/KQ98wIYoJiljDFkoqrfcXf5bnme", + "group": "创新组", + "sender": "徐锐" + }, + { + "time": "2026-05-18 14:05:56", + "url": "https://dianchukeji.feishu.cn/wiki/NSL8whlPbi4Bcmkr0xfcnVcLnxc", + "group": "创新组", + "sender": "韦译" + }, + { + "time": "2026-05-16 00:53:59", + "url": "https://dianchukeji.feishu.cn/wiki/VQxswUOvaiUx36kPiq6cNBERnLg", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-15 23:57:00", + "url": "https://dianchukeji.feishu.cn/wiki/WnGawSdJHixT8NkzanRc2JsFnbg", + "group": "创新组", + "sender": "韦译" + }, + { + "time": "2026-05-15 23:04:17", + "url": "https://dianchukeji.feishu.cn/wiki/QWWCwp79SiwAV2ky2RDcufDCnxe", + "group": "创新组", + "sender": "卓泽" + }, + { + "time": "2026-05-15 00:11:41", + "url": "https://dianchukeji.feishu.cn/wiki/XylZwP9vcirf8bkffnjcbN1onpf", + "group": "创新组", + "sender": "卓泽" + }, + { + "time": "2026-05-14 23:30:28", + "url": "https://dianchukeji.feishu.cn/wiki/QAdawW4l4iaWSIkf0jDcqVxqngb", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-14 21:49:03", + "url": "https://dianchukeji.feishu.cn/wiki/OqVjwMswbiMXHukGZZZcc9g3nnc", + "group": "创新组", + "sender": "韦译" + }, + { + "time": "2026-05-14 01:15:59", + "url": "https://dianchukeji.feishu.cn/wiki/DSD4wa3wBiXGxqkg87icUiHHnoe", + "group": "创新组", + "sender": "韦译" + }, + { + "time": "2026-05-14 00:05:02", + "url": "https://dianchukeji.feishu.cn/wiki/VFeCwF4VsizD4Bkri2Rc62junbf", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-13 22:15:01", + "url": "https://dianchukeji.feishu.cn/wiki/GfgYwRD7Yiyac0kVWOtc9WFjn2c](https://dianchukeji.feishu.cn/wiki/GfgYwRD7Yiyac0kVWOtc9WFjn2c)", + "group": "创新组", + "sender": "卓泽" + }, + { + "time": "2026-05-13 02:14:15", + "url": "https://dianchukeji.feishu.cn/wiki/U32FwRkZPiYu9vkEtXPcRNVVnSe", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-12 22:48:57", + "url": "https://dianchukeji.feishu.cn/wiki/IGr9wUHPUi6dMwkE1s6cVKPfnGe", + "group": "创新组", + "sender": "韦译" + }, + { + "time": "2026-05-12 22:48:29", + "url": "https://dianchukeji.feishu.cn/wiki/ZKeNw6V9ViwCH3kyAM9cOYSpntf", + "group": "创新组", + "sender": "卓泽" + }, + { + "time": "2026-05-12 22:47:25", + "url": "https://dianchukeji.feishu.cn/wiki/NkY6wVzfliQAyykiWsEcaN9cnue", + "group": "创新组", + "sender": "韦译" + }, + { + "time": "2026-05-12 00:22:24", + "url": "https://dianchukeji.feishu.cn/wiki/F8jiwgDmkiyzLMk5KYecuOjinAg", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-11 20:06:34", + "url": "https://dianchukeji.feishu.cn/wiki/YmolwbdlOikKWMkGgQmcTflMnQe", + "group": "创新组", + "sender": "卓泽" + }, + { + "time": "2026-05-10 11:34:30", + "url": "https://dianchukeji.feishu.cn/wiki/RdWtwxGwPi4DRzkhpOEc6S84nsf", + "group": "创新组", + "sender": "卓泽" + }, + { + "time": "2026-05-10 03:02:35", + "url": "https://dianchukeji.feishu.cn/wiki/EpZZw1rT9iBZDFkrwo2cgImpngb", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-09 06:29:32", + "url": "https://dianchukeji.feishu.cn/wiki/CHZiwHehNizCJKkhZqccilaknMd", + "group": "创新组", + "sender": "卓泽" + }, + { + "time": "2026-05-09 01:33:11", + "url": "https://dianchukeji.feishu.cn/wiki/NzSOwDHlgiPCx9klcKWcxzawnhe", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-08 01:50:47", + "url": "https://dianchukeji.feishu.cn/wiki/KRxGwTZ0miRVMMk0fjPcIVv7nge", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-07 22:56:48", + "url": "https://dianchukeji.feishu.cn/wiki/NjkVwE5b2iG9wbksmy5ciSqDnDp", + "group": "创新组", + "sender": "卓泽" + }, + { + "time": "2026-05-07 01:07:15", + "url": "https://dianchukeji.feishu.cn/wiki/FFY7wfiFaig3pMkg9H7cFobFn7g", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-06 21:58:20", + "url": "https://my.feishu.cn/wiki/LSY7we2ceiJ5s5kOJwoclB77nXc", + "group": "创新组", + "sender": "卓泽" + }, + { + "time": "2026-05-01 02:38:52", + "url": "https://dianchukeji.feishu.cn/wiki/Gh8cw3QnJiplq1k2lmFcajidnHl", + "group": "创新组", + "sender": "王雨默" + }, + { + "time": "2026-05-19 01:11:08", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/ErwhdZhR3oJjoNxGB85cQBicnge", + "group": "dc战略问题研究院", + "sender": "胡辉俊" + }, + { + "time": "2026-05-19 01:10:55", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/KlGYddZoOo2UD9xIEVgcNqQ3n5c", + "group": "dc战略问题研究院", + "sender": "夏莲" + }, + { + "time": "2026-05-19 01:10:51", + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/YEAcwAuHkiGwngk4z48cLBzWnth", + "group": "dc战略问题研究院", + "sender": "莫润麟" + }, + { + "time": "2026-05-18 23:55:05", + "url": "https://dianchukeji.feishu.cn/docx/SFrYdULAvo9Z1oxVUHvcReOcncW", + "group": "dc战略问题研究院", + "sender": "陈楚真" + }, + { + "time": "2026-05-17 01:36:07", + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/FFlCweEYqiBlPPkSUzHc1S6bnIc", + "group": "dc战略问题研究院", + "sender": "张家振" + }, + { + "time": "2026-05-17 01:36:02", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/TXNAdSOe2oLdrLxYswZckoR9nUd", + "group": "dc战略问题研究院", + "sender": "夏莲" + }, + { + "time": "2026-05-17 01:35:58", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/V9ejdL4QBo6XpZxWxPDcVNRMnNh", + "group": "dc战略问题研究院", + "sender": "夏莲" + }, + { + "time": "2026-05-16 02:02:49", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/GcKkd0H5EoQY9KxKiSVcZ05VnVc", + "group": "dc战略问题研究院", + "sender": "胡辉俊" + }, + { + "time": "2026-05-16 02:02:48", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/JfNIdEbJ3o9QLOxlaHzcs7X7nkh", + "group": "dc战略问题研究院", + "sender": "夏莲" + }, + { + "time": "2026-05-16 02:02:25", + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/FdI2woTLai6GPDkpPqrcFXYZnGh", + "group": "dc战略问题研究院", + "sender": "莫润麟" + }, + { + "time": "2026-05-16 01:51:05", + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/MKv7w5MX5iW54ykkM7Vcfu6YnTg", + "group": "dc战略问题研究院", + "sender": "张家振" + }, + { + "time": "2026-05-16 01:44:16", + "url": "https://dianchukeji.feishu.cn/docx/M8TId6mhhooxZJxHVc5cAwwXnJh", + "group": "dc战略问题研究院", + "sender": "黄静雯" + }, + { + "time": "2026-05-16 01:42:02", + "url": "https://dianchukeji.feishu.cn/docx/SPnWddkXkoY8GaxIUyocufXBngh", + "group": "dc战略问题研究院", + "sender": "陈楚真" + }, + { + "time": "2026-05-15 09:02:29", + "url": "https://dianchukeji.feishu.cn/docx/SOaBdskVhoSXo0x6gvbcLnKHntb", + "group": "dc战略问题研究院", + "sender": "黄静雯" + }, + { + "time": "2026-05-15 01:46:08", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/BbYMdLdBzoVunRxj51ZcP7gxnFd", + "group": "dc战略问题研究院", + "sender": "胡辉俊" + }, + { + "time": "2026-05-15 01:45:54", + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/LxmkwF7MRiUJInk3V6Mcn5Xanfu", + "group": "dc战略问题研究院", + "sender": "莫润麟" + }, + { + "time": "2026-05-15 01:45:53", + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/HkYPwjIpBiQFeVknIqac7pk4n0e", + "group": "dc战略问题研究院", + "sender": "张家振" + }, + { + "time": "2026-05-15 01:45:47", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/HnNgdyIxso9WWYxCCPLcktDTnLh", + "group": "dc战略问题研究院", + "sender": "夏莲" + }, + { + "time": "2026-05-15 00:36:28", + "url": "https://dianchukeji.feishu.cn/docx/V9fzdn7fZoTSaGxX7yhcwTQUnFc", + "group": "dc战略问题研究院", + "sender": "陈楚真" + }, + { + "time": "2026-05-14 09:29:52", + "url": "https://dianchukeji.feishu.cn/docx/GuJRdtHTKoQ8QaxVbGecxhuDn5Q", + "group": "dc战略问题研究院", + "sender": "黄静雯" + }, + { + "time": "2026-05-14 02:01:40", + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/ZgePwV6s4iMUL0kYiwjcr8ZWnIy", + "group": "dc战略问题研究院", + "sender": "张家振" + }, + { + "time": "2026-05-14 02:01:27", + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/EfDVwSBQIipcL1kG21TcP1ZinKf", + "group": "dc战略问题研究院", + "sender": "莫润麟" + }, + { + "time": "2026-05-14 02:01:15", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/BRyrdjvPboqbX2xjQb4cZnBqnde", + "group": "dc战略问题研究院", + "sender": "胡辉俊" + }, + { + "time": "2026-05-14 02:01:02", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/GaBtddjSqoukwVxGYavcp31zn0e", + "group": "dc战略问题研究院", + "sender": "夏莲" + }, + { + "time": "2026-05-14 01:22:31", + "url": "https://dianchukeji.feishu.cn/docx/Eie1dKsSpoYQkjxUlvdcc5Yknff", + "group": "dc战略问题研究院", + "sender": "陈楚真" + }, + { + "time": "2026-05-13 10:08:50", + "url": "https://dianchukeji.feishu.cn/docx/AhYwdapYjo9Elkx2giXczIK2nno", + "group": "dc战略问题研究院", + "sender": "陈楚真" + }, + { + "time": "2026-05-13 02:58:37", + "url": "https://dianchukeji.feishu.cn/docx/ExYndBzwSoEobXxqgiicDkionnh", + "group": "dc战略问题研究院", + "sender": "黄静雯" + }, + { + "time": "2026-05-13 01:32:57", + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/BVdywLGYyiZFTXkS2nWcHoQ6nmf", + "group": "dc战略问题研究院", + "sender": "莫润麟" + }, + { + "time": "2026-05-13 01:29:02", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/RKktdFgpDovfSJxcDJpcjbbEnHg", + "group": "dc战略问题研究院", + "sender": "胡辉俊" + }, + { + "time": "2026-05-13 01:28:58", + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/W0bjwALE3i2EfSkUxIZcXxtTnAb", + "group": "dc战略问题研究院", + "sender": "张家振" + }, + { + "time": "2026-05-13 01:28:44", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/Kv25dB4ecoMey9xrTZ6cr3REnbc", + "group": "dc战略问题研究院", + "sender": "夏莲" + }, + { + "time": "2026-05-12 01:13:54", + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/XneKwLxUmilaOmkJh8fcRPMInOe", + "group": "dc战略问题研究院", + "sender": "张家振" + }, + { + "time": "2026-05-12 01:11:02", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/Kxkpd6g4Fouc57xQqDucSRQznPe", + "group": "dc战略问题研究院", + "sender": "胡辉俊" + }, + { + "time": "2026-05-12 01:10:56", + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/MgDbwesIkiw7dHkK9YFc3G4Jn8d", + "group": "dc战略问题研究院", + "sender": "莫润麟" + }, + { + "time": "2026-05-12 01:10:47", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/OEOqdSIqFoAWvFxuI2gcz9K4ndc", + "group": "dc战略问题研究院", + "sender": "夏莲" + }, + { + "time": "2026-05-12 00:57:55", + "url": "https://dianchukeji.feishu.cn/docx/N6J5duouUo2ip7xlyBdcJbkYnxg", + "group": "dc战略问题研究院", + "sender": "黄静雯" + }, + { + "time": "2026-05-10 03:33:49", + "url": "https://dianchukeji.feishu.cn/docx/Me8ed6Rfso05rDxG0yBcDfU5n17", + "group": "dc战略问题研究院", + "sender": "黄静雯" + }, + { + "time": "2026-05-10 02:48:38", + "url": "https://dianchukeji.feishu.cn/docx/TLAxdvBokob4xlxlLnHc7VXqnFb", + "group": "dc战略问题研究院", + "sender": "陈楚真" + }, + { + "time": "2026-05-10 02:00:58", + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/LqVQwLuFLiQdamkOchPczt7dnVh", + "group": "dc战略问题研究院", + "sender": "张家振" + }, + { + "time": "2026-05-10 01:54:14", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/FA0FdvarioMIgBx9Swjc4AhWnQe", + "group": "dc战略问题研究院", + "sender": "胡辉俊" + }, + { + "time": "2026-05-10 01:54:05", + "url": "https://fcnlycv6dd0w.feishu.cn/docx/HAt8dakuAox8SQxgZdecY07wnzg", + "group": "dc战略问题研究院", + "sender": "夏莲" + }, + { + "time": "2026-05-10 01:53:59", + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/F0D7wBPASiKt6okdbQWcLGdYnIO", + "group": "dc战略问题研究院", + "sender": "莫润麟" + }, + { + "time": "2026-05-09 03:31:23", + "url": "https://dianchukeji.feishu.cn/docx/UNLydXXQNoGXUCxejlXczf5CnVh", + "group": "dc战略问题研究院", + "sender": "黄静雯" + }, + { + "time": "2026-05-09 01:14:10", + "url": "https://dianchukeji.feishu.cn/docx/UHHWdXKNiowKsExi7hlc4t8rnmb", + "group": "dc战略问题研究院", + "sender": "陈楚真" + }, + { + "time": "2026-05-09 01:00:48", + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/YELvw8sX7iQZGlkZXZRc6iGWnLF", + "group": "dc战略问题研究院", + "sender": "张家振" + }, + { + "time": "2026-05-09 01:00:31", + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/CmznwoDzIi2nLlkCBxTcyd4nnhe", + "group": "dc战略问题研究院", + "sender": "夏莲" + } + ], + "date": "2026-06-02", + "total": 113 +} diff --git a/data/links/feishu_links.txt b/data/links/feishu_links.txt new file mode 100644 index 0000000..3e0ec04 --- /dev/null +++ b/data/links/feishu_links.txt @@ -0,0 +1,87 @@ +https://dianchukeji.feishu.cn/docx/AhYwdapYjo9Elkx2giXczIK2nno?from=from_copylink +https://dianchukeji.feishu.cn/docx/Eie1dKsSpoYQkjxUlvdcc5Yknff?from=from_copylink +https://dianchukeji.feishu.cn/docx/ExYndBzwSoEobXxqgiicDkionnh?from=from_copylink +https://dianchukeji.feishu.cn/docx/GuJRdtHTKoQ8QaxVbGecxhuDn5Q?from=from_copylink +https://dianchukeji.feishu.cn/docx/M8TId6mhhooxZJxHVc5cAwwXnJh?from=from_copylink +https://dianchukeji.feishu.cn/docx/Me8ed6Rfso05rDxG0yBcDfU5n17?from=from_copylink +https://dianchukeji.feishu.cn/docx/N6J5duouUo2ip7xlyBdcJbkYnxg?from=from_copylink +https://dianchukeji.feishu.cn/docx/SFrYdULAvo9Z1oxVUHvcReOcncW +https://dianchukeji.feishu.cn/docx/SOaBdskVhoSXo0x6gvbcLnKHntb +https://dianchukeji.feishu.cn/docx/SPnWddkXkoY8GaxIUyocufXBngh +https://dianchukeji.feishu.cn/docx/TLAxdvBokob4xlxlLnHc7VXqnFb?from=from_copylink +https://dianchukeji.feishu.cn/docx/UHHWdXKNiowKsExi7hlc4t8rnmb?from=from_copylink +https://dianchukeji.feishu.cn/docx/UNLydXXQNoGXUCxejlXczf5CnVh?from=from_copylink +https://dianchukeji.feishu.cn/docx/V9fzdn7fZoTSaGxX7yhcwTQUnFc?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/docx/BRyrdjvPboqbX2xjQb4cZnBqnde?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/docx/BbYMdLdBzoVunRxj51ZcP7gxnFd?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/docx/ErwhdZhR3oJjoNxGB85cQBicnge?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/docx/FA0FdvarioMIgBx9Swjc4AhWnQe?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/docx/GaBtddjSqoukwVxGYavcp31zn0e?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/docx/GcKkd0H5EoQY9KxKiSVcZ05VnVc?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/docx/HAt8dakuAox8SQxgZdecY07wnzg?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/docx/HnNgdyIxso9WWYxCCPLcktDTnLh?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/docx/JfNIdEbJ3o9QLOxlaHzcs7X7nkh?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/docx/KlGYddZoOo2UD9xIEVgcNqQ3n5c?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/docx/Kv25dB4ecoMey9xrTZ6cr3REnbc?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/docx/Kxkpd6g4Fouc57xQqDucSRQznPe?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/docx/OEOqdSIqFoAWvFxuI2gcz9K4ndc?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/docx/RKktdFgpDovfSJxcDJpcjbbEnHg?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/docx/TXNAdSOe2oLdrLxYswZckoR9nUd?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/docx/V9ejdL4QBo6XpZxWxPDcVNRMnNh?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/wiki/BVdywLGYyiZFTXkS2nWcHoQ6nmf +https://fcnlycv6dd0w.feishu.cn/wiki/CmznwoDzIi2nLlkCBxTcyd4nnhe?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/wiki/EfDVwSBQIipcL1kG21TcP1ZinKf +https://fcnlycv6dd0w.feishu.cn/wiki/F0D7wBPASiKt6okdbQWcLGdYnIO +https://fcnlycv6dd0w.feishu.cn/wiki/FdI2woTLai6GPDkpPqrcFXYZnGh +https://fcnlycv6dd0w.feishu.cn/wiki/LxmkwF7MRiUJInk3V6Mcn5Xanfu?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/wiki/MgDbwesIkiw7dHkK9YFc3G4Jn8d +https://fcnlycv6dd0w.feishu.cn/wiki/YEAcwAuHkiGwngk4z48cLBzWnth +https://ocnmca6f1o0p.feishu.cn/wiki/FFlCweEYqiBlPPkSUzHc1S6bnIc?from=from_copylink +https://ocnmca6f1o0p.feishu.cn/wiki/HkYPwjIpBiQFeVknIqac7pk4n0e?from=from_copylink +https://ocnmca6f1o0p.feishu.cn/wiki/LqVQwLuFLiQdamkOchPczt7dnVh?from=from_copylink +https://ocnmca6f1o0p.feishu.cn/wiki/MKv7w5MX5iW54ykkM7Vcfu6YnTg?from=from_copylink +https://ocnmca6f1o0p.feishu.cn/wiki/W0bjwALE3i2EfSkUxIZcXxtTnAb?from=from_copylink +https://ocnmca6f1o0p.feishu.cn/wiki/XneKwLxUmilaOmkJh8fcRPMInOe?from=from_copylink +https://ocnmca6f1o0p.feishu.cn/wiki/YELvw8sX7iQZGlkZXZRc6iGWnLF?from=from_copylink +https://ocnmca6f1o0p.feishu.cn/wiki/ZgePwV6s4iMUL0kYiwjcr8ZWnIy?from=from_copylink +20250520 +https://dianchukeji.feishu.cn/docx/EaIkdelyzoLhlYxQ3KAc7NyUnEf +https://fcnlycv6dd0w.feishu.cn/docx/GjzAdQq32orBdxxNX2WcIFCVnBg?from=from_copylink +https://ocnmca6f1o0p.feishu.cn/wiki/ACLuwapXRiUYX8ktOaNceqftn4g?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/docx/Y97Sdof7MoVPDgxVdygcGbrJnme?from=from_copylink +https://fcnlycv6dd0w.feishu.cn/wiki/KatHwC7e1itotVkGyMFctkiznif +https://my.feishu.cn/docx/QBIbdTcbdoiHYlxI3MocFnQnn3d + +黄静雯: [文件] +陈楚真: [分享]https://dianchukeji.feishu.cn/docx/MWYJd6O6Fo7tLyxJ1s8crV7mn3b?from=from_copylink +夏莲: [分享]https://fcnlycv6dd0w.feishu.cn/docx/QlJydJMAQoLN0KxyWeMcRhCcnub?from=from_copylink +莫润麟: [分享]https://fcnlycv6dd0w.feishu.cn/wiki/OoRZwAfKLiodpnkVIqgcSCXcn35 +胡辉俊: [分享]https://fcnlycv6dd0w.feishu.cn/docx/NnBBdPLZZo24Q5xkzbTcObbMnnd?from=from_copylink +汪季: [分享]https://my.feishu.cn/wiki/JIKHw6Ev6iTjCyk43vAcjNrNnmc?from=from_copylink +张家振: [分享]https://ocnmca6f1o0p.feishu.cn/wiki/UzkTwgGABiD5xwkfiJ8cmgzfnyf?from=from_copylink +陈楚真: [分享]https://dianchukeji.feishu.cn/docx/Etv3dHq9QoZFJuxhAz3cFaVlnIe?from=from_copylink +莫润麟: [分享]https://fcnlycv6dd0w.feishu.cn/wiki/DeOCwJ8GZibah7ktWnmcChjEnWf +夏莲: [分享]https://fcnlycv6dd0w.feishu.cn/docx/PdyKdQnAGoKyrAxBXCocypJgnob?from=from_copylink +张家振: [分享]https://ocnmca6f1o0p.feishu.cn/wiki/Uy6lwM3AtirLc8k9ZsgcO1KtnFg?from=from_copylink +胡辉俊: [分享]https://fcnlycv6dd0w.feishu.cn/docx/NBfLdojWgo2vWkxyyGscbOwcnGd?from=from_copylink +汪季: [分享]https://my.feishu.cn/wiki/URutwqGDMibG2ekxaVxc0wn3nRe?from=from_copylink +夏莲: [分享]https://fcnlycv6dd0w.feishu.cn/docx/IkuadVafvogYbExdqk8ck87nnCf?from=from_copylink +莫润麟: [分享]https://fcnlycv6dd0w.feishu.cn/wiki/VTaRwgxaOiugwykJAxJcxlsxngf +汪季: [分享]https://my.feishu.cn/wiki/RBrcwhIgeiZJGukUxf0c8MXXnSf +胡辉俊: [分享]https://fcnlycv6dd0w.feishu.cn/docx/G3aYd9fHVoYMJExAVSwc6ATdnsF?from=from_copylink +张家振: [分享]https://ocnmca6f1o0p.feishu.cn/wiki/UvZwwsHu5iXkShkNBMacFTrOnEf?from=from_copylink +陈楚真: [分享]https://dianchukeji.feishu.cn/wiki/E2HawE4f1iAB0dkJhCEc98AHnDd?from=from_copylink +黄静雯: [分享]https://dianchukeji.feishu.cn/docx/IJHCdrFJFo3NPfx6wxDcyFV1n1d?from=from_copylink +李志健: [聊天记录] +汪季: [分享]https://my.feishu.cn/wiki/QR6uwinsWikNQnkiQrzcvtUnnDe?from=from_copylink +夏莲: [分享]https://fcnlycv6dd0w.feishu.cn/docx/BrBUdkTEPoCjsCxtxDWcBFsungg?from=from_copylink +莫润麟: [分享]https://fcnlycv6dd0w.feishu.cn/wiki/WYvIwdviniPm7MkpPW7c9IYFnbe +张家振: [分享]https://ocnmca6f1o0p.feishu.cn/wiki/BaZIwUkMli87D4k9raUcuWSBnXe?from=from_copylink +胡辉俊: [分享]https://fcnlycv6dd0w.feishu.cn/docx/LG5ldIeI1obdMXxpPfTc1NWsnsD?from=from_copylink +夏莲: [分享]https://fcnlycv6dd0w.feishu.cn/wiki/TDX6wo4WNifFP7kN0ZjcH5RfnMf?from=from_copylink +汪季: [分享]https://my.feishu.cn/wiki/DTYiwxNROiJM7tkLjigcYnoGnLc?from=from_copylink +胡辉俊: [分享]https://fcnlycv6dd0w.feishu.cn/docx/FeE7dAr3gofk83x2kb0cvbFMnMh?from=from_copylink +陈楚真: [分享]https://dianchukeji.feishu.cn/docx/LOJxdNfW0ohzGlxfDfAc9qIOnyb?from=from_copylink +张家振: [分享]https://ocnmca6f1o0p.feishu.cn/wiki/DHGxwhwGYiBturk1S0xcrmyynre?from=from_copylink +黄静雯: [分享]https://dianchukeji.feishu.cn/docx/RjAtde0SKoIhIRxlwhjcdahtnng?from=from_copylink +黄静雯: [文件] \ No newline at end of file diff --git a/docs/doc_11_Document_11.md b/docs/doc_11_Document_11.md new file mode 100644 index 0000000..24fa910 --- /dev/null +++ b/docs/doc_11_Document_11.md @@ -0,0 +1,151 @@ +# 2026.5.15-鏃ユ姤-鑳¤緣淇奬n +#### **浠婃棩鍐呭姒傝堪锛?* + +##### **1.姊崇悊寮€棰樻ā鍧楃殑鍐呭閫昏緫涓庨〉闈㈣皟鏁存柟鍚?* + +**2.鏁寸悊鍚庣画闇€鍚屾鏇存柊鐨勬牳蹇冩憳瑕佷笌棰勮閲嶇偣闂** + + + +### 涓€. 寮€棰楶PT鍐呭涓庡竷灞€璋冩暣 + +> 鐜扮増PPT瑙嗚椋庢牸骞插噣锛屼絾瀛樺湪 **淇℃伅鍘嬬缉杩囧害銆佸叧閿爺绌跺唴瀹规湭琚粨鏋勫寲鍛堢幇** 鐨勯棶棰? +> 鍥犳璋冩暣鏂瑰悜閲囩敤锛?*閫傚綋绮剧畝鏂囧瓧 + 缁撴瀯鍖栬〃杈?+ 鍥剧ず鍛堢幇** +> +> **鐩爣鏄湪涓嶅鍔犻〉闈㈣礋鎷呯殑鍓嶆彁涓嬶紝鑳藉鐪嬪埌鐮旂┒鍐呭鐨勫畬鏁存€э紝骞朵繚鎸佸亸绠€娲佺殑瑙嗚鍋忓ソ** + + + +#### 鏁版嵁鏉ユ簮涓庢牱鏈粨鏋刓n +##### **锛?锛夋牳蹇冧綋鐜板唴瀹逛笌涓讳綋閫昏緫** + +- **鏍稿績涓嶆槸鍗曠函灞曠ず鏁版嵁瑙勬ā锛岃€屾槸璇存槑锛?* + +> **鏈爺绌剁殑鏁版嵁鑳藉鏀拺鈥滀釜浣撯€斿洟浣撯€旇禌灞€鈥旂珵璧涒€濈殑澶氬眰鍒嗘瀽缁撴瀯锛屽苟涓哄悗缁彉閲忚璁′笌缁忛獙璇嗗埆鎻愪緵鍩虹銆?* + +- **涓讳綋閫昏緫鍙鎷负锛?* + +**鏁版嵁鏉ユ簮锛?*銆婂彨鎴戜竾宀佺埛銆嬭繍钀ュ悗鍙版暟鎹紝鑱氱劍**璺ㄦ湇鍥綋绔炶禌銆佺兘鐏€愮洘**绛夌湡瀹炰笟鍔″満鏅€俓n +**鏍锋湰缁撴瀯锛?* 閫氳繃鍘嗗彶绔炶禌鏁版嵁锛屽睍绀虹爺绌?*鏍锋湰鐨勮妯′笌绋冲畾鎬?* + +**鏁版嵁浠峰€硷細鍏ㄩ摼璺暟鎹彲鑾峰彇**锛?*瑙勫垯妗嗘灦鐩稿绋冲畾**锛?*鍦烘櫙杈圭晫娓呮櫚** + +鍥犳锛屾湰椤靛簲鎵挎媴鐨勫姛鑳芥槸锛歕n +> 浠?*鎴戜滑鏈変粈涔堟暟鎹?*杩涗竴姝ヨ鏄庡埌**杩欎簺鏁版嵁涓轰粈涔堣冻浠ユ敮鎾戝悗缁缓妯′笌鏈哄埗璇嗗埆** + + +**涓庘€滅爺绌跺満鏅笌瀵硅薄鐣屽畾鈥濅腑宓屽缁撴瀯鐨勫姛鑳藉樊寮?* +**鐮旂┒瀵硅薄鐣屽畾 涓殑** 涓綋 鈭?鍥綋 鈭?璧涘眬 鈭?绔炶禌锛岄噸鐐瑰洖绛旂殑鏄細 +> **鐮旂┒涓轰粈涔堜笉鑳藉彧鐪嬩釜浣擄紵涓轰粈涔堣浠庡灞傚祵濂楃粨鏋勭悊瑙e洟浣撹禌瀛e埗绔炶禌锛?* +**鏁版嵁鏉ユ簮涓庢牱鏈粨鏋?*鐨勯噸鐐规槸**鏁版嵁缁撴瀯璇存槑**锛屽洖绛旂殑鏄細 +> **鏁版嵁鏄惁瑕嗙洊澶氬眰缁撴瀯锛熸槸鍚︽敮鎾戝彉閲忚璁″拰缁忛獙璇嗗埆锛?* + + +#### **璋冩暣鍓?涓?璋冩暣鍚?* + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=YmJlMGU0MmI0MDhmMjRjMmJiMmM5ZjY4MDQyMWZkMWJfNWIyYjdkNDBmYmRmOGU3ODg5MjIwNmVjNjE4MzU5OWJfSUQ6NzY0MDE2OTAzOTMyNjY3ODIxMl8xNzc5MTc2MTE3OjE3NzkxNzk3MTdfVjM) + +#### **鏍稿績缁撴灉鍙橀噺锛氱患鍚堟姇鍏?* + +**锛?锛夋牳蹇冧綋鐜板唴瀹逛笌涓讳綋閫昏緫** + +- 鏍稿績涓嶆槸璇︾粏瑙i噴鍙橀噺鏋勯€犵殑鍏ㄩ儴鎶€鏈粏鑺傦紝鑰屾槸璇存槑锛歕n +> **涓嶉噰鐢ㄥ崟涓€浠樿垂鎴栧崟涓€鍦ㄧ嚎鏃堕暱锛岀敤鈥滅患鍚堟姇鍏モ€濈粺涓€鍒荤敾绔炶禌鏈熷唴鐨勬湁鏁堥噾閽辨姇鍏ヤ笌鏈夋晥鏃堕棿鎶曞叆銆?* + +- **甯冨眬璁捐閫昏緫** + +閲囩敤 **鈥滀富缁撹 + 鍏紡 + 鍙屾爮瀵圭収 + 搴曢儴璇存槑鈥?* 鐨勪笁灞傜粨鏋刓n +**涓荤粨璁猴細**璇存槑缁煎悎鎶曞叆鐢ㄤ簬**缁熶竴鍒荤敾绔炶禌鏈熷唴鐨勯噾閽辨姇鍏?*涓?*鏈夋晥鏃堕棿**鎶曞叆 + +**鏍稿績鍏紡涓嶬/L瀵圭収锛?*璇存槑涓や釜鏋勬垚缁村害鐨?*缁熻鍙e緞**銆?*鎺掗櫎鑼冨洿**鍜?*澶勭悊鏂瑰紡** + +**蹇呰瑙i噴锛?*绠€鐭鏄庡洖搴斾袱涓叧閿棶棰橈紝**涓轰粈涔堜笉鐢ㄥ崟涓€鎸囨爣锛?鏉冮噸濡備綍璁惧畾**锛焅n +#### **璋冩暣鍓?涓?璋冩暣鍚?* + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=MDBlMmY1ODllZGRiNjAwYWQ0ZDBkNDBmNGFhNDYyOGJfZTY4NGU5ODA0MmQzMDM2MzQzYjY5ZTA3OGY3ZDdiYjBfSUQ6NzY0MDE2OTU4MjUxMDAxNzUwOF8xNzc5MTc2MTE3OjE3NzkxNzk3MTdfVjM) + +#### **鏈哄埗鍙橀噺鏋勫缓锛氫粠鐞嗚鏈哄埗鍒板叆妯$壒寰?* + +**锛?锛夋牳蹇冧綋鐜板唴瀹逛笌涓讳綋閫昏緫** + +- 鏍稿績鏄ˉ瓒?**鈥滀竷鏈哄埗鐞嗚妗嗘灦鈥濅笌鈥滄満鍣ㄥ涔犵粡楠岃瘑鍒€濅箣闂寸殑涓棿妗ユ**锛屽洖绛旓細 + +> **鐞嗚鏈哄埗濡備綍杞寲涓烘ā鍨嬪彲浠ヨ瘑鍒殑鍙橀噺锛?* + +- **涓讳綋閫昏緫涓猴細鐞嗚鏈哄埗涓嶈兘鐩存帴鍏ユā锛岄渶瑕佸畬鎴愬彉閲忚浆鍖栭摼璺?* +- **閫氳繃浠ヤ笅璺緞瀹屾垚鏈哄埗鍙橀噺鏋勫缓锛?* + +> **鐞嗚鏈哄埗 鈫?涓氬姟瑙勫垯 鈫?鍚庡彴瀛楁 鈫?鏈哄埗鍙橀噺 鈫?鍏ユā鐗瑰緛** + +- **灞曠ず浠h〃鎬ф槧灏勬牱渚?* + + - **鍏钩鎬?*锛氬叧娉?*璧涘眬鑳藉姏宸紓鏄惁鍙帶**锛屽搴斿疄鍔涘樊寮傘€佸己寮卞樊璺濄€佸尮閰嶅潎琛″害 + - **浜掕ˉ鎬?*锛氬叧娉?*閲戦挶涓庢椂闂存姇鍏ユ槸鍚﹀崗鍚?*锛屽搴擪-L鍗忓悓鍏崇郴銆佹湁鏁堣涓哄瘑搴︺€佸崗浣滄姇鍏ョ粨鏋? + - **绉佹湁鎬?*锛氬叧娉?*璐$尞鍥炴姤鏄惁鏈夋晥缁戝畾**锛屽搴斾釜浜鸿础鐚€笺€佸鍔遍鍙栥€佽础鐚?濂栧姳鍖归厤搴n +#### **鏂板鍐呭椤?* + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=Nzk4NWIxM2E2NzljNzRmYzk2NmEzYzUyNzVmYWJlZDZfNTVlMzMzOTAxYjNhZjIwYTEzNGVhNDYyMGM2MzhjOGZfSUQ6NzY0MDEwNjg2MDQwNTkxODg5OF8xNzc5MTc2MTE3OjE3NzkxNzk3MTdfVjM) + +#### 缁忛獙璇嗗埆鏂规硶涓庡紓璐ㄦ€у垎鏋怽n +**锛?锛夋牳蹇冧綋鐜板唴瀹逛笌涓讳綋閫昏緫** + +- 鏍稿績涓嶆槸浠嬬粛绠楁硶鍘熺悊锛岃€屾槸璇存槑锛? + +> 鏈哄埗鍙橀噺杩涘叆妯″瀷鍚庯紝濡備綍璇嗗埆鍏抽敭鏈哄埗銆佽В閲婁綔鐢ㄥ舰鎬侊紝骞惰繘涓€姝ユ瘮杈冧笉鍚岀兢浣撶殑鍝嶅簲宸紓 + +- **涓讳綋閫昏緫鍙互姒傛嫭涓猴細** + +**鍏ㄦ牱鏈粡楠岃瘑鍒細XGBoost + SHAP** + +**鍏堝湪鍏ㄦ牱鏈眰闈㈣瘑鍒叧閿満鍒跺彉閲忓強鍏朵綔鐢ㄥ舰鎬?* + +- **XGBoost**锛氬洖绛斺€滃摢浜涙満鍒跺彉閲忔洿鍏抽敭锛熲€? + 杈撳嚭鍙橀噺閲嶈鎬ф帓搴忥紝鐢ㄤ簬璇嗗埆浼樺厛鍏虫敞鐨勫叧閿満鍒躲€? +- **SHAP**锛氬洖绛?*鍏抽敭鍙橀噺濡備綍褰卞搷缁煎悎鎶曞叆**锛? + 杈撳嚭褰卞搷鏂瑰悜銆佸叧绯诲舰鎬佸拰鍏抽敭鍖洪棿锛屼緥濡傛鍚戝寮恒€侀€傚害鏈€楂樸€佽竟闄呰秼缂? +- **鍒嗙粍寮傝川鎬у垎鏋愶細鑱氱被 + 鍒嗙粍璇嗗埆** + +> **鍦ㄥ叏鏍锋湰璇嗗埆鍩虹涓婏紝杩涗竴姝ラ€氳繃鑱氱被褰㈡垚缇や綋鏍囩锛屽苟鍦ㄤ笉鍚岀兢浣撳唴閲嶅XGBoost + SHAP鍒嗘瀽** + +- **涓ら儴鍒嗗唴瀹逛箣闂寸殑琛旀帴** + +> **鍏ㄦ牱鏈瘑鍒叧閿満鍒?鈫?瑙i噴鏈哄埗浣滅敤褰㈡€?鈫?鑱氱被褰㈡垚缇や綋鏍囩 鈫?鍒嗙粍姣旇緝鏈哄埗鍝嶅簲宸紓 鈫?鏀拺宸紓鍖栨不鐞?* + +#### **鍦ㄥ師鐗堝熀纭€涓婁紭鍖?* + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=MDYyMWQxOTUzNGY0NzE4NGQ1MGU0MGM0Y2JlOWM2N2RfNGU5N2QzNTk1ODJmMjNlOWNkNTFiYzgwNmY2NWQ1YjFfSUQ6NzY0MDE0MjMxNTE1OTM5MTE4OF8xNzc5MTc2MTE3OjE3NzkxNzk3MTdfVjM) + +#### **娌荤悊杈撳嚭璺緞锛氫粠妯″瀷缁撴灉鍒拌鍒欎紭鍖?* + +**锛?锛夋牳蹇冧綋鐜板唴瀹逛笌涓讳綋閫昏緫** + +- 鏍稿績涓嶆槸缁х画灞曠ず妯″瀷鏂规硶锛岃€屾槸璇存槑锛? + +> **妯″瀷缁撴灉濡備綍缁忚繃鏈哄埗璇婃柇涓庤鍒欐槧灏勶紝鏈€缁堣浆鍖栦负鍙墽琛岀殑瑙勫垯浼樺寲鏂瑰悜** + +- 閲囩敤 **鈥滃洓姝ヨ浆鍖栭摼璺?+ 绀轰緥 + 娌荤悊鏂瑰悜鈥?* 鐨勭粨鏋刓n +**鍥涙杞寲閾捐矾锛?* + +> 妯″瀷缁撴灉 鈫?鏈哄埗璇婃柇 鈫?瑙勫垯鏄犲皠 鈫?娌荤悊寤鸿 + +杩欐潯閾捐矾璇存槑**妯″瀷缁撴灉涓嶄細鐩存帴绛夊悓浜庣鐞嗗缓璁?*锛岃€屾槸**闇€瑕佺粡杩囦腑闂磋浆鍖?*锛屾墠鑳?*褰㈡垚鍙墽琛岀殑瑙勫垯浼樺寲鏂瑰悜** + +**绀轰緥閾捐矾锛?* + +> 瀹炲姏绂绘暎搴﹁繃楂?鈫?鍏钩鎬ф満鍒跺け琛?鈫?鍖归厤/琛ュ伩瑙勫垯 鈫?鎺у埗寮哄急宸窛 + +鐢ㄤ簬璇存槑濡備綍浠庝竴涓?*妯″瀷璇嗗埆缁撴灉**锛岃浆鍖栦负**鏈哄埗璇婃柇鍜岃鍒欎紭鍖?*鏂瑰悜 + +**娌荤悊鏂瑰悜锛?* + +- **缁撴灉绠$悊 鈫?杩囩▼娌荤悊**锛氱敤杩囩▼鎸囨爣璇嗗埆鎶曞叆琛板噺涓庣珵浜夊け琛? +- **缁熶竴瑙勫垯 鈫?鍒嗗眰娌荤悊**锛氬熀浜庣兢浣撳樊寮傚疄鏂藉樊寮傚寲瑙勫垯閰嶇疆 +- **鐭湡鍒烘縺 鈫?鐢熸€佷紭鍖?*锛氫粠鏈哄埗灞傞潰缁存寔闀挎湡鍙備笌涓庣粍缁囩ǔ瀹? + +**璋冩暣鍓?涓?璋冩暣鍚?* + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=ZmVkYmQyYWQxNmMzOTQ3MzQwMjcwNDVjYTcxNDgzMDNfYmNiNTBhM2VjMmExZWFjNjBkYmZiNzk0YmYyZTA2NjhfSUQ6NzY0MDE3MTc5OTA2NTQ4MDM4NV8xNzc5MTc2MTE3OjE3NzkxNzk3MTdfVjM) + + +- **浠婃棩涓昏鍥寸粫寮€棰樺唴瀹逛腑璐熻矗鐨勬ā鍧楄繘琛屽唴瀹逛紭鍖?* +- 鏄庢棩鐨勯噸鐐规槸瀹屾垚璐熻矗妯″潡鍏ㄩ儴鍐呭椤甸潰鐨勬渶缁堜紭鍖栬皟鏁碶n- 鍚屾椂鍚屾鏇存柊**鏍稿績鎽樿鍜岄璁鹃噸鐐归棶棰樺唴瀹?*锛岀‘淇漃PT灞曠ず銆佹眹鎶ラ€昏緫鍜岀瓟杈╁噯澶囦笁鑰呬繚鎸佷竴鑷碶n diff --git a/docs/doc_14_Document_14.md b/docs/doc_14_Document_14.md new file mode 100644 index 0000000..54da6a9 --- /dev/null +++ b/docs/doc_14_Document_14.md @@ -0,0 +1,106 @@ +# 2026.05.18-鏃ユ姤-澶忚幉 + +## 涓€銆佸伐浣滃唴瀹规杩癨n +1. 瀹屾垚涓変唤姹囨姤鏂囨。锛氭枃瀛楃増鎶ュ憡銆丳PT鎶ュ憡銆佹暣鏀规姤鍛奬n2. 浜嗚В瀛︽湳鐮旂┒Agent + + + +## 浜屻€佷簡瑙e鏈爺绌?Agent + +杩戜竴骞达紝瀛︽湳 AI Agent 鐮旂┒浠庡崟鐐硅緟鍔╁伐鍏疯浆鍚戜簡鈥滅鐮旀祦绋嬪瀷 Agent鈥濄€備富瑕佽鐩栨枃鐚绱€佸亣璁剧敓鎴愩€佷唬鐮佸疄楠屻€佹暟鎹垎鏋愩€佸浘琛ㄧ敓鎴愩€佽鏂囧啓浣滃拰鑷垜璇勪及绛夌幆鑺傘€俓n + + +### **锛堜竴锛夌鐮斿崗浣滆€呯被 Agent** + +**浠h〃锛歋ciSciGPT銆丟oogle AI co-scientist** + +寮鸿皟鍦ㄤ汉绫荤爺绌惰€呬富瀵间笅锛孉I 浣滀负绉戠爺鍔╂墜鎴栧崗浣滆€呭弬涓庡叿浣撶幆鑺傘€備富瑕佸府鍔╃爺绌惰€呭畬鎴愭枃鐚悊瑙c€侀棶棰樻媶瑙c€佹暟鎹垎鏋愩€佺粨鏋滆В閲婂拰鐮旂┒鏂规鐢熸垚銆俓n +#### 銆?*SciSciGPT**銆慭n +**璁烘枃锛歋ciSciGPT: advancing human鈥揂I collaboration in the science of science** + +**鍙戣〃鏈熷垔 | 骞翠唤锛歂ature Computational Science锛?025 骞?12 鏈堬級** + +> 瑙e喅鐨勯棶棰橈細璁烘枃璁や负锛岀幇鍦ㄧ鐮旇秺鏉ヨ秺渚濊禆澶ц妯℃暟鎹拰澶嶆潅璁$畻鏂规硶锛屼絾杩欎細甯︽潵寰堥珮鐨勬妧鏈棬妲涖€傜爺绌惰€呭彲鑳芥湁鐮旂┒闂锛屼絾闇€瑕佽嚜宸卞畬鎴愭暟鎹簱鐞嗚В銆佹暟鎹竻娲椼€丼QL 鏌ヨ銆佷唬鐮佸垎鏋愩€佸彲瑙嗗寲鍜岀粨鏋滄鏌ワ紝鏁堢巼浣庛€侀棬妲涢珮銆俓n> +> 甯歌绉戠爺鍒嗘瀽娴佺▼锛氭枃鐚绱?鈫?鎵炬暟鎹?鈫?鐞嗚В鏁版嵁搴撶粨鏋?鈫?鍐?SQL / Python / R 鈫?鍋氱粺璁″垎鏋?鈫?鐢诲浘 鈫?妫€鏌ョ粨鏋?鈫?鍙嶅淇敼銆俓n +#### **绯荤粺鏋舵瀯锛? 澶ф櫤鑳戒綋鍗忓悓** + +1. **ResearchManager 锛堟€绘帶-鎷嗚В浠诲姟锛?* +2. **LiteratureSpecialist锛堟枃鐚笓瀹讹級** + +璐熻矗绉戝瀛﹂鍩熸枃鐚绱€佺煡璇嗘彁鍙栥€佺患杩扮敓鎴愪笌寮曠敤婧簮鐨勪笓涓氭櫤鑳戒綋锛屾牳蹇冮€氳繃棰嗗煙涓撳睘妫€绱㈠寮虹敓鎴愭灦鏋勫疄鐜扮簿鍑嗙煡璇嗚皟鐢紝闄嶄綆澶фā鍨嬪够瑙夐闄┿€俓n +**瀹屾暣宸ヤ綔娴佺▼锛?* + +- 鏍规嵁鐢ㄦ埛鐨勭爺绌堕棶棰橈紝鐢熸垚瑙勮寖鐨勬绱㈤棶棰榎n- LLM 鑷姩璇嗗埆骞跺簲鐢ㄥ厓鏁版嵁杩囨护鏉′欢锛屽彲闄愬畾浠呮绱㈡枃鐚殑鎽樿銆佹柟娉曘€佺粨鏋溿€佽璁虹瓑鐗瑰畾绔犺妭 +- 浣跨敤 HyDE锛堝亣璁炬枃妗e祵鍏ワ級 鐢熸垚澶氫釜涓庨棶棰樼浉鍏崇殑 鈥滃亣璁炬钀解€漒n- 鐢ㄨ繖浜涘亣璁炬钀戒笌SciSciCorpus锛堢瀛﹀鏂囩尞搴擄級涓殑鏂囨湰鐗囨杩涜鍚戦噺鐩镐技搴﹀尮閰峔n- 瀵规绱㈠埌鐨勫唴瀹硅繘琛屾暣鍚堛€佸綊绾充笌瑙h锛岀敓鎴愬甫瀛︽湳寮曠敤鐨勭患杩版€у洖绛擻n +**鏍稿績鍔熻兘琛ュ厖锛?* + +- 鍙牴鎹棶棰橀渶瑕侊紝瀵规憳瑕併€佹柟娉曘€佺粨鏋溿€佽璁虹瓑涓嶅悓鏂囩尞鐗囨杩涜鍒嗗眰妫€绱紝閫愭娣卞寲鐞嗚В銆俓n- 浠ョ湡瀹炴枃鐚绱㈢粨鏋滀负鍩虹鐢熸垚鍥炵瓟锛屽寮哄唴瀹圭殑鍙拷婧€у拰瀛︽湳鍙潬鎬с€俓n +> HyDE锛堝亣璁炬枃妗e祵鍏ワ級 = 鍏堢敤 AI 缂栦竴娈?鈥滄剰鎬濈浉杩戔€?鐨勫亣绛旀锛屽啀鎷垮畠鍘荤簿鍑嗘壘鍒扮湡鏂囩尞銆俓n +1. **DatabaseSpecialist锛堟暟鎹笓瀹舵櫤鑳戒綋锛?* + +璐熻矗瀛︽湳鏁版嵁鑾峰彇銆佹暟鎹粨鏋勭悊瑙c€佹暟鎹彁鍙栥€佹暟鎹竻娲椾笌鏍囧噯鍖栫殑涓撲笟鏅鸿兘浣擄紝鏍稿績瀵规帴瀛︽湳鏁版嵁搴撴暟鎹熀纭€銆俓n +**宸ヤ綔娴佺▼锛?* + +- 鎺ユ敹鏁版嵁浠诲姟锛屾槑纭渶瑕佸摢浜涙暟鎹€佽寖鍥翠笌鏉′欢銆俓n- 鑷姩璇诲彇骞剁悊瑙f暟鎹簱鐨勮〃缁撴瀯锛岀煡閬撴暟鎹瓨鏀惧湪鍝紶琛ㄣ€佸摢浜涘瓧娈点€俓n- 鏍规嵁浠诲姟闇€姹傦紝鑷姩鐢熸垚瀵瑰簲鐨勬暟鎹簱鏌ヨ璇彞锛屼粠 SciSciNet 涓彁鍙栫洰鏍囨暟鎹€俓n- 瀵规満鏋勫悕绉般€佷綔鑰呭悕绉般€佹枃鐚俊鎭瓑杩涜缁熶竴鏍囧噯鍖栧鐞嗭紝閬垮厤鍥犲悕绉板啓娉曚笉鍚屽鑷村垎鏋愰敊璇€俓n- 瀹屾垚鏁版嵁娓呮礂銆佸幓閲嶃€佹牸寮忚浆鎹紝鐢熸垚鍙洿鎺ョ敤浜庡垎鏋愮殑骞插噣鏁版嵁銆俓n +**鍔熻兘琛ュ厖锛?* + +- 鑳藉澶勭悊鍗冧竾绾у埆鐨勮鏂囥€佸紩鐢ㄣ€佸悎浣滅綉缁溿€佹満鏋勫叧绯荤瓑澶ц妯″鏈暟鎹€俓n- 鑷姩鐞嗚В澶嶆潅鐨勬暟鎹叧绯伙紝涓嶉渶瑕佷汉宸ュ啓鏌ヨ璇彞鎴栨暣鐞嗘暟鎹€俓n +1. **AnalyticsSpecialist锛堝垎鏋愪笓瀹舵櫤鑳戒綋锛?* + +璐熻矗鏁版嵁缁熻鍒嗘瀽銆佹ā鍨嬫瀯寤恒€佷唬鐮佽嚜鍔ㄧ紪鍐欎笌绉戠爺鍥捐〃鍙鍖栫殑涓撲笟鏅鸿兘浣擄紝渚濇墭闅旂瀹夊叏鐨勪唬鐮佽繍琛岀幆澧冿紝瀹屾垚浠庢暟鎹埌绉戠爺缁撹鐨勫叏娴佺▼璁$畻宸ヤ綔銆俓n +**宸ヤ綔娴佺▼锛?* + +- 鎺ユ敹鎸囦护锛岃鍙栧凡娓呮礂瀹屾垚鐨勮鑼冩暟鎹€俓n- 鏍规嵁鐮旂┒闇€姹傦紝鑷姩閫夋嫨鍚堥€傜殑鍒嗘瀽鏂规硶锛屽寘鎷弿杩扮粺璁°€佸洖褰掑垎鏋愩€佺綉缁滃垎鏋愩€佽仛绫诲垎鏋愩€佸洜鏋滃垎鏋愮瓑銆俓n- 鍦ㄥ畨鍏ㄩ殧绂荤殑浠g爜娌欑鐜涓紝鑷姩缂栧啓鍙繍琛岀殑浠g爜锛屾敮鎸?Python銆丷銆丣ulia銆俓n- 杩愯浠g爜瀹屾垚鏁板€艰绠椼€佹寚鏍囨彁鍙栥€佸叧绯婚獙璇佷笌瑙勫緥鎸栨帢锛屽緱鍒伴噺鍖栧垎鏋愮粨鏋溿€俓n- 鏍规嵁鏁版嵁鐗瑰緛涓庝换鍔¤姹傦紝鑷姩鐢熸垚涓撲笟绉戠爺鍥捐〃锛屽鍚堜綔缃戠粶鍥俱€佸弻杞磋秼鍔垮浘銆佸垎甯冨姣斿浘绛夈€俓n +**鍔熻兘琛ュ厖锛?* + +- 鏃犻渶浜哄伐缂栧啓浠g爜锛岃嚜鍔ㄥ畬鎴愪粠鏁版嵁鍒板浘琛ㄧ殑鍏ㄦ祦绋嬪垎鏋愩€俓n- 鏀寔澶嶆潅绉戠爺鍦烘櫙锛屽彲澶嶇幇椤跺垔璁烘枃涓殑鍥捐〃涓庣粺璁$粨璁恒€俓n +1. **EvaluationSpecialist锛堣瘎浼颁笓瀹舵櫤鑳戒綋锛夊畬鏁寸増** + +璐熻矗鍏ㄦ祦绋嬭川閲忔鏌ャ€佺粨鏋滄墦鍒嗐€侀棶棰樿瘖鏂笌鏀硅繘寤鸿鐨勭洃鐫e瀷鏅鸿兘浣擄紝閫氳繃澶氱骇璇勪及鏈哄埗淇濋殰鏁翠釜绉戠爺娴佺▼鍙潬銆佸噯纭€佽鑼冦€俓n +**宸ヤ綔娴佺▼锛?* + +- 鍏ㄧ▼鐩戞帶鍏朵粬鏅鸿兘浣撶殑鎵ц杩囩▼锛屽湪鍏抽敭姝ラ瀹屾垚鍚庡惎鍔ㄨ瘎浼般€俓n- 寮€灞?*宸ュ叿浣跨敤璇勪及**锛氭鏌ユ暟鎹煡璇€佹枃鐚绱€佷唬鐮佽皟鐢ㄧ瓑鎿嶄綔鏄惁姝g‘銆佸悎鐞嗐€俓n- 寮€灞?*鍥捐〃鍙鍖栬瘎浼?*锛氭鏌ュ浘琛ㄦ竻鏅板害銆侀厤鑹层€佹爣娉ㄣ€佸竷灞€鏄惁瑙勮寖锛岀粰鍑轰紭鍖栧缓璁€俓n- 寮€灞?*鏁翠綋浠诲姟璇勪及**锛氭鏌ユ暣涓瓙浠诲姟鏄惁瀹屾暣杈炬垚鐩爣锛屾柟娉曢€夋嫨鏄惁绉戝銆俓n- 瀵规瘡涓€椤圭粨鏋滆繘琛岄噺鍖栨墦鍒嗭紝鏍规嵁鍒嗘暟鍒ゆ柇鏄惁閫氳繃銆佹槸鍚﹂渶瑕佷慨姝f垨閲嶅仛銆俓n +**鍔熻兘琛ュ厖锛?* + +- 鑷姩绾犻敊銆佽嚜鍔ㄦ彁鍗囩粨鏋滆川閲忋€傝绯荤粺鍏峰鑷垜淇鑳藉姏锛屾彁鍗囧垎鏋愬彲闈犳€т笌瀛︽湳涓ヨ皑鎬с€俓n- 鏈夋晥鍑忓皯澶фā鍨嬮敊璇€佷唬鐮佹紡娲炪€佸浘琛ㄤ笉瑙勮寖绛夐棶棰樸€俓n +--- + +**瀵规瘮锛歋ciSciGPT銆丟oogle AI co-scientist** + + + + + +### **锛堜簩锛夌鍒扮鑷姩绉戠爺绫?Agent** + +> 浠h〃锛欰I-Researcher銆丄gent Laboratory +> +> - 灏濊瘯璁?AI 浠庣爺绌舵兂娉曞嚭鍙戯紝鑷姩瀹屾垚鏂囩尞妫€绱€佺爺绌跺亣璁剧敓鎴愩€佸疄楠岃璁°€佷唬鐮佸疄鐜般€佺粨鏋滃垎鏋愩€佸浘琛ㄧ敓鎴愬拰璁烘枃鍒濈鎾板啓绛夊畬鏁存祦绋嬨€俓n> - 杩欑被鐮旂┒鏇村己璋冣€滅鐮旀祦绋嬭嚜鍔ㄥ寲鈥濓紝灞曠ず AI 鍙備笌瀹屾暣鐮旂┒闂幆鐨勫彲鑳芥€э紝浣嗙洰鍓嶄粛浠ュ師鍨嬫帰绱负涓伙紝涓嶈兘鐩存帴鏇夸唬鐮旂┒鑰呭畬鎴愭寮忚鏂囥€俓n +#### 銆怉I-Researcher銆慭n +鏁翠綋鐩爣鏄敖閲忚嚜鍔ㄥ畬鎴愮鐮旀祦绋嬨€傝鏂囨憳瑕佷腑璇达紝瀹冭鐩栦粠 **鏂囩尞缁艰堪銆佸亣璁剧敓鎴愩€佺畻娉曞疄鐜帮紝鍒板彲鍙戣〃璁烘枃鍑嗗** 鐨勫畬鏁撮摼璺紝骞舵彁鍑?Scientist-Bench 鏉ヨ瘎浠疯嚜鍔ㄧ鐮旇兘鍔涖€俓n +1. **杈撳叆闃舵锛氫袱绉嶅惎鍔ㄦ柟寮?*鎻愪緵鏄庣‘鐮旂┒鎯虫硶锛孉I 甯姪鎵ц鍙粰鍙傝€冩枃鐚紝AI 鑷富鐢熸垚鎯虫硶骞舵墽琛孿n2. **鏂囩尞缁艰堪涓庣爺绌舵兂娉曠敓鎴?* + + > 鏌ヨ祫鏂?鈫?绛涜祫鏂?鈫?鎵剧┖鐧?鈫?鐢熸垚鐮旂┒鎯虫硶 + + 1. 鑷姩鏀堕泦鐮旂┒璧勬枡锛屽寘鎷鏂囥€佷唬鐮佷粨搴撳拰寮€鏀炬暟鎹泦 + 2. 绛涢€夐珮璐ㄩ噺璧勬簮锛屼緥濡傞珮褰卞搷鍔涜鏂囥€佺淮鎶よ緝濂界殑浠g爜銆佸畬鏁村害杈冮珮鐨勬暟鎹泦 + 3. 鍩轰簬绛涢€夊悗鐨勮祫婧愶紝鍒嗘瀽宸叉湁鏂规硶灞€闄愩€佹妧鏈秼鍔垮拰娼滃湪绌虹櫧锛岀敓鎴愭柊鐨勭爺绌舵柟鍚慭n3. **绠楁硶璁捐銆佸疄鐜颁笌楠岃瘉** + + > 鎯虫硶璁捐 鈫?鍐欐垚浠g爜 鈫?璺戝疄楠?鈫?鐪嬬粨鏋?鈫?缁х画浼樺寲 + + 1. 鎶婄爺绌舵兂娉曡浆鎴愮畻娉曟柟妗堬紝寤虹珛鐞嗚鍩虹鍜屽疄鐜扮瓥鐣n 2. 鎶婃娊璞℃柟妗堝啓鎴愬叿浣撲唬鐮侊紝鎼缓瀹為獙鐜鍜屽姛鑳芥ā鍧梊n 3. 杩愯瀹為獙锛屾敹闆嗘寚鏍囷紝楠岃瘉绠楁硶琛ㄧ幇 + 4. 鏍规嵁瀹為獙缁撴灉鍙戠幇闂锛屼紭鍖栦唬鐮併€佹敼杩涙柟娉曪紝骞惰繘鍏ヤ笅涓€杞凯浠n4. **缁撴灉鍒嗘瀽涓庤鏂囧啓浣?* + + > 瑙i噴缁撴灉 鈫?缁勭粐璁烘枃缁撴瀯 鈫?鐢熸垚瀹屾暣璁烘枃 + + 1. 鍒嗘瀽瀹為獙缁撴灉锛岃В閲婃寚鏍囪〃鐜般€佹柟娉曚紭鍔垮拰涓嶈冻 + 2. 鏁村悎鐮旂┒鍔ㄦ満銆佹柟娉曡璁°€佸疄楠岀粨鏋滃拰鍒嗘瀽鍐呭 + 3. 杈撳嚭杈冨畬鏁寸殑瀛︽湳璁烘枃鏂囨湰 +5. **鍩哄噯娴嬭瘯涓庤川閲忚瘎浠?*璇勪环鑷姩绉戠爺绯荤粺鐨勪骇鍑鸿川閲忥細鐮旂┒鏄惁鏈夊垱鏂版€с€佸疄楠屾槸鍚﹀厖鍒嗐€佺悊璁哄熀纭€鏄惁鎵庡疄銆佺粨鏋滆В閲婃槸鍚﹀噯纭€佽鏂囧啓浣滄槸鍚︽竻鏅拌繛璐痋n +--- + + +**SciSciGPT鍜孉I-Researcher缃戦〉鐗堣瘯鐢?* +涓や釜閮芥湁寮€婧愮増鏈紝涔熼兘鏈夊湪绾跨綉椤靛舰寮忓彲浠ヤ綋楠岋紝浣嗗畾浣嶅拰浣跨敤鏂瑰紡涓嶄竴鏍枫€俓n**SciSciGPT锛?* +- 鏇村亸鍚戞枃鐚绱€佺鐮旀暟鎹垎鏋愬拰鍙鍖栥€傚畠鍙互杩炴帴API锛屽湪缁欏畾鍏蜂綋鐮旂┒鑼冨洿鍚庯紝杈呭姪瀹屾垚鑷姩妫€绱€佹枃鐚悊瑙c€佹暟鎹簱鏌ヨ銆佹暟鎹垎鏋愬拰缁撴灉瑙i噴銆俓n- 涓嶈繃锛屼富瑕佽繕鏄搮闀跨瀛﹀鐮旂┒鍦烘櫙锛堝垎鏋愯鏂囥€佷綔鑰呫€佸紩鐢ㄧ瓑瀛︽湳鏁版嵁锛夈€佸鏋滅敤鍒板叾浠栧绉戯紝鍙兘闇€瑕佽皟鏁存暟鎹簮銆佸叧閿瘝銆佸垎鏋愭祦绋嬪拰鏈湴閮ㄧ讲閰嶇疆銆俓n- 鍙互鍊熼壌鈥滄枃鐚?+ 鏁版嵁 + 鍙鍖栤€濇柟闈㈢殑娴佺▼锛屼互鍙婂浣曟媶瑙e垎鏋愪换鍔°€俓n**AI-Researcher** +- 缃戦〉鐗堟媶鎴愪簡寰堝涓ā鍧楋紝鍙互鎸夌爺绌堕樁娈靛垎鍒€夋嫨銆傚寘鎷細瀹屾暣鐮旂┒娴佺▼銆佹枃鐚患杩般€佺爺绌舵兂娉曠敓鎴愩€佹柟娉曡璁°€佽嚜鍔ㄥ疄楠屻€佹暟鎹垎鏋愩€佸鐜拌鏂囥€備娇鐢ㄨ繃绋嬩篃姣旇緝鍍忓璇濆紡鎿嶄綔锛氳緭鍏ョ爺绌堕棶棰樻垨鑰呬笂浼犺祫鏂欙紝鐒跺悗閫夋嫨涓嶅悓妯″潡锛岃 Agent 鎸夐樁娈电敓鎴愮粨鏋溿€俓n- 鍙互瀛︿範锛氫笉鍚岄樁娈靛搴斾笉鍚?Agent锛屽悇涓ā鍧椾箣闂存€庢牱涓茶仈璧锋潵銆傚悗缁粨鍚堝紑婧愪唬鐮佽繘涓€姝ヤ簡瑙fā鍧楀疄鐜般€佹彁绀鸿瘝璁捐鍜屽伐鍏疯皟鐢ㄦ柟寮忋€俓n鎴戜滑鐩墠鐨勭爺绌朵篃鍙互鎷嗗垎鎴愮被浼肩殑瀛愭ā鍧楋細鏂囩尞鍩虹 鈫?鐮旂┒绌虹櫧 鈫?涓冩満鍒舵鏋?鈫?鍙橀噺璁捐 鈫?鏁版嵁鍙e緞妫€鏌?鈫?XGBoost / SHAP 瀹為獙 鈫?缁撴灉瑙i噴 鈫?娌荤悊寤鸿銆備粖澶╄繖涓や釜姣旇緝鍋忓悜绉戠爺Agent绯荤粺锛岄噸鐐规槸瀛︿範瀹冧滑濡備綍鎷嗗垎绉戠爺娴佺▼銆佽缃垎宸ュ崗浣溿€傛槑澶╄瘯涓€涓媋cademic-research-skills銆俓n diff --git a/docs/doc_16_Document_16.md b/docs/doc_16_Document_16.md new file mode 100644 index 0000000..daf7adb --- /dev/null +++ b/docs/doc_16_Document_16.md @@ -0,0 +1,175 @@ +# 2026.05.16-鏃ユ姤-娣卞湷鐮旂┒閮ㄦ棩鎶n +## 涓€銆佸伐浣滃唴瀹规杩癨n +1. 閽堝璋冩暣闂杩涜鏁存敼 + + + +## 浜屻€侀棶棰樻暣鏀筡n +#### 锛堜竴锛夆€滃浜衡€濇蹇甸渶瑕佸墠缃氦浠n +**鎻愬嚭闂锛?* + +鐩墠瀵光€滃浜衡€濈殑瑙i噴涓嶅娓呮櫚銆傞渶瑕佸湪璁鸿堪鍓嶆璁叉竻妤氬浜虹殑鍏蜂綋鍚箟锛屼互鍙婂洿缁曡繖涓€涓婚瑕佽В鍐充粈涔堟牳蹇冮棶棰橈紝骞堕€氳繃鏂囩尞缁艰堪鏀拺鍏抽敭闂鐨勬彁鍑恒€俓n +**璋冩暣璇存槑锛?*宸叉柊澧炲苟鍓嶇疆鈥滃浜虹ぞ浜ょ珵浜夆€濈殑姒傚康鐣屽畾鍐呭銆俓n +**宸茶皟鏁村唴瀹癸細** + +1. **鏂板鈥滄蹇电晫瀹氾細澶氫汉绀句氦绔炰簤娓告垙** +鎵€绉扳€滃浜烘父鎴忊€濆苟闈炵畝鍗曟寚浜烘暟锛岃€屾槸涓綋宓屽叆鍥綋銆佸洟浣撹繘鍏ヨ禌灞€銆佽禌灞€缃簬绔炶禌涓殑澶氬眰宓屽绔炰簤缁撴瀯锛屽洜姝ゅ钩鍙版不鐞嗙殑閲嶇偣涓嶅啀鍙槸鍗曞眬鑳滆礋锛岃€屾槸鎸佺画鎶曞叆銆佺粍缁囧崗浣滀笌鐢熸€佺ǔ瀹氥€俓n2. **琛ュ厖鈥滃崟浜?/ 绠€鍗曠珵鎶€鈥濅笌鈥滃浜虹ぞ浜ょ珵浜夆€濈殑瀵规瘮** +浠庢牳蹇冮┍鍔ㄨ绱犮€佷氦浜掔壒寰併€佸钩鍙拌鑹插拰绠$悊閲嶇偣鍥涗釜鏂归潰璇存槑鍖哄埆銆? +3. **绐佸嚭鏈枃鐮旂┒瀵硅薄鐨勫灞傚祵濂楃粨鏋?* +閫氳繃缁撴瀯鍥惧睍绀轰釜浣撱€佸洟浣撱€佽禌灞€銆佺珵璧涗箣闂寸殑灞傜骇鍏崇郴锛岃鏄庢寔缁姇鍏ヤ笉鏄崟涓€鐢ㄦ埛琛屼负锛岃€屾槸澶氬眰缁撴瀯鍏卞悓浣滅敤鐨勭粨鏋溿€? + + + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=NDIzYTNhOGM4NTM2ODRmMDFlNWVkNWQ3NWNmMGYxMTBfODVmM2RlZDMyMTQyNjlhNWQwZjg1NjM1YmI2NjJhYzJfSUQ6NzY0MDUzNDA1ODcwMjgzNDY2NF8xNzc5MTc2MTIwOjE3NzkxNzk3MjBfVjM) + + + + +--- + +#### 锛堜簩锛夎儗鏅儴鍒嗗叧閿悊璁洪敋鐐归渶瑕佹洿绐佸嚭 + +**鎻愬嚭闂锛?* + +褰撳墠寮€棰樻姤鍛婁腑鈥滀粠澧為噺鍒板瓨閲忕粡钀ャ€佸钩鍙版不鐞嗕綋绯绘瀯寤恒€佹満鍒惰璁°€佸埗搴﹁В鍐斥€濈瓑鍏抽敭鐞嗚閿氱偣瀛樺湪鎰熷亸寮憋紝闇€瑕佽繘涓€姝ョ獊鍑恒€俓n +**璋冩暣璇存槑锛?*鑳屾櫙閮ㄥ垎宸查噸鏂板己鍖栫悊璁洪敋鐐圭殑閫掕繘琛ㄨ揪銆俓n +**宸茶皟鏁村唴瀹癸細** + +1. **绐佸嚭鈥滀粠澧為噺鎵╁紶鍒板瓨閲忕粡钀モ€?* +閫氳繃琛屼笟鏁版嵁璇存槑娓告垙琛屼笟鐢ㄦ埛绾㈠埄鍑忓急锛屽钩鍙板闀块噸蹇冧粠鏂板鐢ㄦ埛鎵╁紶杞悜鐜版湁鐢ㄦ埛闀挎湡鍙備笌鍜屾繁搴﹁繍钀ャ€? +2. **绐佸嚭鈥滆鍒欐満鍒垛€濅綔涓哄钩鍙版不鐞嗗伐鍏?* +鏄庣‘璇存槑锛氭姇鍏ヨ“鍑忎笉鏄崟绾唴瀹瑰惛寮曞姏涓嬮檷锛岃€屾槸瑙勫垯鏈哄埗濡備綍褰卞搷鍙備笌鑰呮寔缁姇鍏ョ殑闂銆? +3. **琛ュ厖鏂囩尞鍩虹涓庣爺绌剁┖鐧?* +灏嗗钩鍙版不鐞嗐€佹父鎴忓弬涓庛€佺珵璧涜璁″拰鍥㈤槦鍗忎綔绛夋枃鐚綔涓虹悊璁哄熀纭€锛岃鏄庣幇鏈夌爺绌跺鍥綋璧涘鍒剁珵璧涗腑鐨勨€滆鍒欐満鍒垛€旀寔缁姇鍏モ€濊В閲婁粛涓嶈冻銆? +4. **杩涗竴姝ヨ惤鍒扮爺绌堕棶棰樹笌娌荤悊璺緞** +灏嗙爺绌堕棶棰樻暣鐞嗕负鈥滄満鍒舵娊璞°€佸叧閿瘑鍒€佸叧绯昏В閲娿€佸紓璐ㄦ€ф不鐞嗏€濆洓涓€掕繘闂锛屼负鍚庣画瑙勫垯浼樺寲鍜屾不鐞嗚緭鍑哄仛閾哄灚銆? + +--- + +#### 锛堜笁锛夎儗鏅儴鍒嗛渶瑕佷粠鍏蜂綋娓告垙闂鍒囧叆 + +**鎻愬嚭闂锛?* + +1. 铏界劧缁撴瀯瀹屾暣锛屼絾娓告垙琛屼笟鏈€鏈夌壒鑹层€佹渶鏈夌敾闈㈡劅鐨勫唴瀹规病鏈夊睍绀哄嚭鏉ャ€傝鍔犲叆鐪熷疄娓告垙鎴浘銆佺帺瀹跺姩鎬佸拰涓氬姟鍦烘櫙锛岃鐞嗚妗嗘灦鏈夊叿浣撹惤鑴氱偣銆俓n2. 寤鸿涓€寮€濮嬩粠浼佷笟鍏蜂綋娓告垙闂鍒囧叆锛屽厛灞曠ず骞堕獙璇侀棶棰樺瓨鍦紝鍐嶇敤鐞嗚鏈哄埗灞曞紑锛岃繖鏍烽€昏緫鏇存湁璇存湇鍔涖€俓n +**璋冩暣璇存槑锛?*宸插鍔犵湡瀹炴父鎴忓唴瀹瑰拰涓氬姟鍦烘櫙灞曠ず銆俓n +**宸茶皟鏁村唴瀹癸細** + +1. **琛ュ厖鐮旂┒鍦烘櫙閫夋嫨** +璇存槑鏈枃鑱氱劍銆婂彨鎴戜竾宀佺埛銆嬭法鏈嶅洟浣撹禌瀛e埗绔炶禌锛岃鍦烘櫙鍏锋湁闀垮懆鏈熴€佸己鍗忎綔銆佺粍缁囧寲鍜屾寔缁珵浜夌壒寰併€? +2. **灞曠ず浼佷笟鐪熷疄闂** +閫氳繃鎶曞叆鍙樺寲鏇茬嚎銆佷笟鍔$棝鐐瑰拰娓告垙鎴浘锛屽睍绀哄洟浣撶珵璧涗腑瀛樺湪鐨勬姇鍏ヨ“鍑忛棶棰橈紝鍖呮嫭锛?绔炰簤澶辫 銆佹縺鍔卞け鏁?銆佹姇鍏ユ尋鍑?銆?鍗忎綔鏂 +3. **鐢ㄦ父鎴忚鍒欐埅鍥捐鏄庤鍒欏浣曠粍缁囨姇鍏?* +灏嗗洓绫讳笟鍔¢棶棰樺搴斿埌鍏蜂綋瑙勫垯鏈哄埗锛? + + - 绔炰簤澶辫  鈫?鍖归厤涓庡垎缁勮鍒? + - 婵€鍔卞け鏁?鈫?绉垎涓庡鍔辫鍒? + - 鎶曞叆鎸ゅ嚭 鈫?浠樿垂涓庤涓鸿鍒? + - 鍗忎綔鏂 鈫?鍗忎綔涓庣粍缁囪鍒? +4. **璇存槑涓轰粈涔堥€夋嫨鍥綋璧涘鍒剁珵璧?* +浠?PVP銆乀VT 鍒?GVG 鍥綋璧涘鍒剁珵璧涜繘琛屽姣旓紝绐佸嚭鏈枃鐮旂┒鍦烘櫙鐨勫吀鍨嬫€n +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=YTcwMmYzM2MyOGQ3Y2FlYzkwZTNiMzc1ZDcxNzBhNjNfNGEyNzFlNmViOTBiOTJjYjU3N2YwMDQyOGE2ZDIyZGFfSUQ6NzY0MDUzNDU5MTM0OTk4NDIwMV8xNzc5MTc2MTIwOjE3NzkxNzk3MjBfVjM) + +--- + +#### 锛堝洓锛夌鐞嗛棶棰橀渶瑕佹彁寰楁洿澶n +**鎻愬嚭闂锛?* + +鍘熻儗鏅棶棰樺鏄撳眬闄愬湪娓告垙琛屼笟鍐呴儴锛屽缓璁皢鍏朵笂鍗囦负鏇存櫘閬嶇殑绠$悊闂锛屽嵆缁勭粐濡備綍鎸佺画婵€娲诲唴閮ㄦ垚鍛樺拰澶栭儴鍚堜綔鑰呮姇鍏ワ紝浠庤€屽寮虹爺绌剁殑鎴樼暐鎰忎箟鍜岃法琛屼笟鍚ず銆俓n +**璋冩暣璇存槑锛?*宸插湪鑳屾櫙閮ㄥ垎瀵归棶棰樻剰璇嗚繘琛屼簡鎻愬崌銆俓n +娓告垙琛屼笟鐨勫瓨閲忕珵浜夛紝鎶樺皠鍑烘洿鏅亶鐨勭鐞嗛棶棰橈細鍦ㄥ灞傚祵濂楃粍缁囦腑锛屽浣曢€氳繃瑙勫垯鏈哄埗鎸佺画婵€娲绘垚鍛樹笌鍚堜綔鑰呯殑鎶曞叆銆俓n +**宸茶皟鏁村唴瀹癸細** + +1. **浠庤涓氬瓨閲忕粡钀ュ紩鍑洪暱鏈熷弬涓庨棶棰?* +璇存槑娓告垙琛屼笟杩涘叆瀛橀噺鏃朵唬鍚庯紝骞冲彴鏍稿績闂浠庘€滃浣曡幏寰楁洿澶氭柊鐢ㄦ埛鈥濊浆鍚戔€滃浣曠淮鎸佺幇鏈夌敤鎴锋寔缁弬涓庝笌闀挎湡鎶曞叆鈥濄€? +2. **灏嗘姇鍏ヨ“鍑忓畾涔変负绯荤粺鎬ч棶棰?* +涓嶅啀鎶婇棶棰樿〃杩颁负鍗曚釜鐜╁涓嶆椿璺冿紝鑰屾槸寮鸿皟澶氶噸瑙勫垯鍥犵礌鍏卞悓褰卞搷涓嬬殑绯荤粺鎬ф姇鍏ヨ“鍑忋€? + +--- + +#### 锛堜簲锛夋枃鐚垎鏋愰儴鍒嗛渶瑕佸湪 PPT 涓綋鐜癨n +**鎻愬嚭闂锛?* + +澧炲姞鏂囩尞鍒嗘瀽鍐呭锛岃鏄庣幇鏈夋枃鐚湁鍝簺鍊煎緱鎺㈣鐨勭┖鐧姐€俓n +**宸茶皟鏁村唴瀹癸細** + +1. **鏂囩尞绌虹櫧椤?* +鎸囧嚭骞冲彴闇€瑕侀€氳繃瑙勫垯鏈哄埗缁存寔鍥綋璧涘鍒剁珵璧涗腑鐨勬寔缁弬涓庯紝浣嗙洰鍓嶄粛缂轰箯绯荤粺妗嗘灦瑙i噴鍝簺瑙勫垯浼氫績杩涙姇鍏ワ紝鍝簺瑙勫垯浼氬紩鍙戞姇鍏ヨ“鍑忎笌鍗忎綔寮卞寲銆? +2. **褰掔撼鐜版湁鐮旂┒涓嶈冻涓轰笁鐐癸細** + + - 澶氭暟鐮旂┒鍋忓悜鍗曚汉琛屼负銆佺煭鏈熸椿璺冩垨鍗曚竴鏈哄埗锛? + - 瀵瑰洟浣撹禌瀛e埗绔炶禌涓殑瑙勫垯鏈哄埗銆佹寔缁姇鍏ュ拰澶氬眰鍗忎綔缂轰箯鏁村悎瑙i噴锛? + - 缂哄皯鈥滃鏉傝鍒欐潯娆?鈫?鏈哄埗鎶借薄 鈫?鍙橀噺鏄犲皠 鈫?缁忛獙璇嗗埆 鈫?娌荤悊寤鸿鈥濈殑瀹屾暣璺緞銆? +3. **琛ュ厖浠h〃鏂囩尞鏀拺锛?*椤甸潰搴曢儴宸叉斁鍏ヤ唬琛ㄦ枃鐚甛n +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=ZWE0OWRjYzc0NDljN2I3N2YyZmI2YjEwY2E5OGU3NTRfYWJmN2YyYWRhNzE2MjExM2JlMjNmZDhjYWYzNDg3YzdfSUQ6NzY0MDUzNTI5NzUxOTkxNDIwNl8xNzc5MTc2MTIwOjE3NzkxNzk3MjBfVjM) + +--- + +#### **锛堝叚锛変竷鏈哄埗鍦≒PT涓渶瑕佹湁涓绘湁娆★紝涓嶈兘骞冲潎灞曞紑** + +**鎻愬嚭闂锛?* + +涓冧釜鏈哄埗涓嶈兘鍦≒PT涓钩鍧囩敤鍔涳紝搴旀槑纭噸鐐硅瘑鍒€佽緟鍔╄В閲婂拰鎺㈢储鎬ф満鍒跺悇鑷殑鍔熻兘瀹氫綅銆傚惁鍒欒鑰呮棤娉曞垽鏂摢浜涙満鍒舵槸鍚庣画缁忛獙鍒嗘瀽鐨勬牳蹇冿紝鍝簺鍙槸鐞嗚妗嗘灦鐨勮ˉ鍏呫€俓n +**璋冩暣璇存槑锛?* + +灏嗗師鍏堢畝鍗曠殑涓夌被鏈哄埗缃楀垪锛屽崌绾т负瀹屾暣鐨勫彲璇嗗埆鎬у垎灞傞€昏緫椤点€傞噸鐐硅娓呬笁涓棶棰橈細涓轰粈涔堣鍒嗗眰銆佷緷鎹粈涔堝垎灞傘€佸垎灞傚悗鍚勮嚜鎵挎媴浠€涔堢爺绌跺姛鑳姐€傞〉闈㈤《閮ㄦ瀯寤烘牳蹇冮€昏緫閾撅細 + +> 涓冩満鍒舵鏋?鈫?鏁版嵁鏀拺鍒ゆ柇 鈫?璇嗗埆涓绘鍒嗗眰 鈫?瑙i噴杈圭晫鏄庣‘ + +**宸茶皟鏁村唴瀹癸細** + +鍒嗗眰缁撴灉濡備笅锛歕n + + +1. 鍒嗗眰渚濇嵁鍥涢」鏍囧噯锛氬彲瑙傛祴鎬с€佸彉寮傚害銆佹暟鎹眰绾с€佽В閲婅竟鐣屻€俓n + + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=ODc4M2VhMWNiMGZlYWFmNThjMTU3NjhhZjhmM2VmNzZfYzg0NTRkZGI5ODljZTg2OThkOTMxODc0MGFkMjg4NDhfSUQ6NzY0MDUzMzM1NjAyMjYxNTIzM18xNzc5MTc2MTIwOjE3NzkxNzk3MjBfVjM) + + + + +--- + +#### **锛堜竷锛変竷鏈哄埗瑕佸垎寮€灞曞紑璁诧紝璁╃悊璁哄垱鏂扮偣鍦≒PT涓綋鐜板嚭鏉?* + +**鎻愬嚭闂锛?* + +涓冩満鍒堕渶瑕佸垎鍒睍寮€锛岀獊鍑烘瘡涓満鍒剁殑鍐呮兜銆佺悊璁烘敮鎾戙€佹牳蹇冨弬鏁板拰浼佷笟妗堜緥锛岃鐞嗚鎬у垱鏂扮偣鐪熸鍦≒PT涓綋鐜板嚭鏉ワ紝鑰屼笉鏄彧鍋滅暀鍦ㄦ枃瀛楃増寮€棰樻姤鍛婁腑銆俓n +**璋冩暣璇存槑锛?* + +浼樺厛灞曞紑涓夐」閲嶇偣璇嗗埆鏈哄埗鈥斺€斿叕骞虫€с€佷簰琛ユ€с€佺鏈夋€э紝姣忎釜鏈哄埗缁熶竴閲囩敤鍥涘眰缁撴瀯锛氭満鍒跺叧娉ㄣ€佺悊璁烘ā鍨嬨€佹牳蹇冨弬鏁般€佷笟鍔℃渚嬶紝浣挎満鍒跺唴瀹规棦鏈夌悊璁烘敮鎾戯紝鍙堣兘涓庝紒涓氱湡瀹炵珵璧涚帺娉曞彂鐢熷搴斻€俓n +**宸茶皟鏁村唴瀹癸細** + +- **鍏钩鎬э細** 璧涘眬鑳藉姏宸紓鏄惁鍙帶 鈫?鍥綋鑳藉姏鏍囧噯宸?鈫?鏍稿績鍙傛暟 蟽x 鈫?銆婄兘鐏€愮洘銆嬮€氳繃鍥藉姏鍒嗗尯鎺у埗寮哄急宸窛 +- **浜掕ˉ鎬э細** 閲戦挶鎶曞叆涓庢椂闂存姇鍏ヨ兘鍚﹀崗鍚?鈫?CES鐢熶骇鍑芥暟 鈫?鏇夸唬寮规€?蟽 鈫?榧撹垶銆佹淳閬d笌璧勬簮鎶曞叆鍏卞悓椹卞姩璧涘眬鎺ㄨ繘 +- **绉佹湁鎬э細** 涓汉璐$尞涓庣浜哄洖鎶ユ槸鍚︾粦瀹?鈫?鎸夎础鐚唤棰濆垎閰嶇殑鏁堢敤琛ㄨ揪寮?鈫?璐$尞绉佹湁鍖栫郴鏁?鈫?鎹愮尞鎶藉銆佺珵鐚滄敹鐩娿€佽疆娆′釜浜哄鍔卞己鍖栬础鐚€斿洖鎶ョ粦瀹歕n + + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=ZTllMWJkYjJkODdjZDkwNDVjN2E0Y2QzOTcxOTY5NTRfNzk5OTQ0Y2Q5NDAwMjIxMjhmMzMzOGY2ZmU5NDZlZWRfSUQ6NzY0MDUzMzg5Nzk5MzgzMzQyMl8xNzc5MTc2MTIwOjE3NzkxNzk3MjBfVjM) + + + + +--- + +#### **锛堝叓锛夎緟鍔╀笌鎺㈢储鎬ф満鍒跺悓鏍烽渶瑕佸睍寮€锛屼絾鍛堢幇鏂瑰紡瑕佷笌閲嶇偣鏈哄埗鏈夋墍鍖哄垎** + +**鎻愬嚭闂锛?* + +涓冩満鍒堕兘闇€瑕佸睍寮€璁诧紝涓嶈兘鍙睍寮€閲嶇偣鏈哄埗銆傚悓鏃跺己璋冧笉鍚屽眰绾ф満鍒剁殑鍛堢幇鏂瑰紡瑕佹湁鍖哄垎锛屼笉鑳藉叏閮ㄥ钩閾哄睍寮€銆佷富娆′笉娓呫€備袱涓缓璁渶瑕佸悓鏃跺洖搴斻€俓n +**璋冩暣璇存槑锛?* + +娌跨敤涓庨噸鐐规満鍒剁浉鍚岀殑鍥涘眰缁撴瀯鈥斺€旀満鍒跺叧娉ㄣ€佺悊璁烘ā鍨嬨€佹牳蹇冨弬鏁般€佷笟鍔℃渚嬶紝淇濊瘉椤甸潰鏍峰紡涓€鑷淬€佸舰鎴愯繛缁槄璇讳綋楠屻€傚悓鏃堕€氳繃鍒嗗眰鏍囨敞鍖哄垎閲嶇偣璇嗗埆涓庤緟鍔╂帰绱㈡満鍒剁殑鍔熻兘瀹氫綅锛岄伩鍏嶅钩鍧囩敤鍔涖€傛縺鍔辨€ч儴鍒嗕篃杩涗竴姝ュ惛鏀朵簡姝ゅ墠鍏钩鎬т笌婵€鍔辨€ц竟鐣屽帢娓呯殑鏂囧瓧鐗堜慨鏀归€昏緫銆俓n +**宸茶皟鏁村唴瀹癸細** + +- **琛ュ伩鎬э細** 鎶曞叆宸窛濡備綍杞寲涓虹粨鏋滃樊璺?鈫?濉旀礇鍏嬪啿绐佹垚鍔熷嚱鏁?鈫?鍙傛暟 r锛堟姇鍏モ€旂粨鏋滆浆鍖栨晱鎰熷害锛夆啋 澶嶅彫浠ゃ€侀紦鑸炵瓑瑙勫垯褰卞搷钀藉悗鏂硅拷璧剁┖闂碶n- **婵€鍔辨€э細** 濂栧姳姊害鑳藉惁鎸佺画婵€鍙戞姇鍏?鈫?涓ゆ柟濂栧姳姊害鎺ㄥ 鈫?澶氬悕娆$粨鏋勪互鍩哄凹绯绘暟 G 鍒荤敾 鈫?鏅嬫。銆佷繚妗d笌鍚嶆濂栧姳宸紓褰卞搷鎸佺画鎶曞叆鎰忔効 +- **浜掑姩鎬э細** 鍥綋闂寸珵浜変簰鍔ㄨ兘鍚︽寔缁縺娲?鈫?閲嶅鍗氬紙涓嬩綆绔炰簤鍚堜綔绋虫€佸垽鏂?鈫?璐寸幇鍥犲瓙 未 鈫?杞鍘婚噸銆佸尮閰嶉噸缁勭瓑瑙勫垯閬垮厤榛樺閬挎垬 +- **娴佸姩鎬э細** 缁勭粐缁撴瀯鏄惁闀挎湡鍥哄寲 鈫?瑙勬ā鎵╁紶涓庢垚鏈嚫鎬у叧绯?鈫?鎴愭湰鍑告€х郴鏁?b 鈫?鎴愬憳娴佸姩闂ㄦ涓庤仈鐩熻妯¤竟鐣屽奖鍝嶅ご閮ㄩ泦鑱歕n + + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=Mzg1NTYzYTVkYzQyMzliYTM4ZTA2NGY4M2QyNWZhODVfODE5ZDg1ZDBjMjYwMGYyNTYwNjUzZjU1ZWQzNTc5M2FfSUQ6NzY0MDUzMzg2MjQ3NjUxNjU1NV8xNzc5MTc2MTIwOjE3NzkxNzk3MjBfVjM) + + + + +--- diff --git a/docs/doc_20_Document_20.md b/docs/doc_20_Document_20.md new file mode 100644 index 0000000..c0f1899 --- /dev/null +++ b/docs/doc_20_Document_20.md @@ -0,0 +1,64 @@ +# 2026.5.16-鏃ユ姤-寮犲鎸痋n +## 宸ヤ綔鍐呭姒傝堪 + +1銆佸弬鍔犺€佹潕鐨勬父鎴忚 + +--- + +## 涓€銆佹父鎴忚瀛︿範瑕佺偣 + +### 锛堜竴锛夎璁¤寖寮忓洓澶у叧閿厓绱燶n +- **鍦熷湴涓庣┖闂寸害鏉?* + +杩欐槸鐜囧湡-Like鏈€搴曞眰鐨勮鍒欏熀鐭炽€傜帺瀹剁殑涓€鍒囪涓烘渶缁堥兘鎸囧悜鍦熷湴銆?*瀹冩槸鍞竴璧勬簮鏉ユ簮銆佹垬鍔涙姇灏勭殑杞戒綋锛屾洿鏄禌瀛g粓鏋佺洰鏍囨湰韬?*銆傛牳蹇冮搧寰嬪彧鏈変竴鏉★細**鍙兘鏀诲崰涓庤嚜宸遍鍦扮浉閭荤殑鏍煎瓙**銆傝繖鏉$畝鍗曡鍒欙紝灏嗘暣寮犲湴鍥惧彉鎴愬法澶х殑鎴樼暐妫嬬洏锛屾瘡涓€娆℃墿寮犻兘蹇呴』涓€瀵镐竴瀵稿湴鈥滈摵璺€濄€傜┖闂寸敱姝よ浆鍖栦负鏈€绋€缂虹殑璧勬簮锛屽叧鍙c€佺爜澶淬€佸场璋峰洜涔嬫垚涓哄繀浜変箣鍦帮紝**閾鸿矾鐨勬柟鍚戙€侀€熷害涓庤矾绾块€夋嫨锛屾湰韬氨鏄竴鍦烘棤澹扮殑鎴樹簤**銆俓n +- **寮哄埗鑱旂洘** + +鐜囧湡-Like浠庤璁′笂灏?*鎷掔粷浜嗙嫭鐙?*銆備笉鍔犲叆鍚岀洘锛屾案杩滄棤娉曡Е鍙婅禌瀛g殑鏈€缁堣儨鍒┾€斺€旀敾鍗犳礇闃炽€佸ず鍙栭湼涓氭墍闇€鐨勫叺鍔涜妯′笌璧勬簮璋冨害锛岃繙瓒呬换浣曚釜浣撴墍鑳戒紒鍙娿€傝繖鏈川涓婃槸涓€绉嶁€?*寮虹ぞ浜?*鈥濓細鏃犺鐜╁鎬ф牸濡備綍銆佸亸濂戒綍绉嶇帺娉曪紝鍙鎯充綋楠屽畬鏁村唴瀹癸紝灏卞繀椤昏繘鍏ラ泦浣擄紝杩涜€屽嵎鍏ュ垎宸ャ€佹矡閫氥€佷俊浠汇€佽儗鍙涖€佸浜よ繖涓€鏁村浜虹被绀句細鐨勭粡鍏告垙鍓с€?*寮哄埗鑱旂洘锛屾槸鏁翠釜鍝佺被绀句氦鐢熸€佺殑鍙戝姩鏈?*銆俓n +- **鍏钩鎴樻枟** + +鍏钩鎴樻枟鏄巼鍦?Like涓庘€滄暟鍊肩⒕鍘嬪瀷鈥濇父鎴忕殑**鍒嗘按宀?*銆傛牳蹇冧富寮犲緢鏄庣‘锛?*鎴樻枟缁撴灉搴旂敱绛栫暐鍐崇瓥鐨勮川閲忓喅瀹氾紝鑰岄潪鐢辫皝鑺遍挶鏇村銆佽皝鍏ュ潙鏇存棭鏉ュ喅瀹?*銆傛暟鍊兼湁褰卞搷锛屼絾涓嶈兘鏄喅瀹氭€х殑銆備粠浜у搧婕旇繘鐪嬶紝鏂瑰悜娓呮櫚鑰屽潥瀹氾細涓嶆柇鍑忓皯绾暟瀛楀樊寮傦紝涓板瘜绛栫暐缁村害锛屾嫈楂樺崥寮堜环鍊笺€傘€婄巼鍦熶箣婊ㄣ€嬪缓绔嬩簡鍩虹鐨勫厠鍒朵笌鎴樻硶妗嗘灦锛屻€婁笁鍥藉織路鎴樼暐鐗堛€嬪湪鎶€鑳借璁′笌闃靛鎼厤涓婃寔缁繁鍖栵紝銆婁笁鍥借皨瀹氬ぉ涓嬨€嬪垯杩涗竴姝ラ€氳繃鎴樻硶鍙戝姩鐜囩殑绋冲畾鍖栬璁°€佸钩姘戔€滅闃熲€濈殑涓诲姩濉戦€狅紝**璁┾€滅瓥鐣ユ纭€濇瘮鈥滃厖鍊兼洿澶氣€濇洿鏈夊垎閲?*銆俓n +- **璧涘鍒?* + +娓告垙鐜╀箙浜嗭紝澶撮儴浼樺娍婊氶洩鐞冭埇鑶ㄨ儉锛屽悗鏉ヨ€呯炕鐩樻棤鏈涳紱鑰屽ぇ閮ㄥ垎鐩爣杈炬垚鍚庯紝鐜╁鍙堜細鍧犲叆鏃犱簨鍙仛鐨勭┖铏氥€傝禌瀛e埗鐨勭瓟妗堝共鑴嗗埄钀斤紝**瀹氭湡閲嶇疆璧涘眬锛岀炕鐩橀噸鏉?*銆傚畠杩涜浜嗙簿缁嗗寲鐨勫彇鑸嶏細**淇濈暀涓汉璧勪骇锛堟灏嗐€佹垬娉曘€佽澶囷級涓庢搷浣滅粡楠岋紝閲嶇疆鏈嶅姟鍣ㄧ姸鎬侊紙鍦熷湴褰掗浂銆佸煄姹犳槗涓汇€佸悓鐩熸礂鐗岋級**銆傝繖鍒涢€犲嚭涓€绉嶇嫭鐗逛綋楠屸€斺€斾綘姣斾笂涓禌瀛f洿寮轰簡锛屼絾闈㈠鐨勫眬闈㈠張鏄叏鏂扮殑銆傝禌瀛f椂闀垮喅瀹氱帺瀹跺涔呰繘鍏ョ柌鍔虫湡锛屼篃妗嗗畾浜嗗晢涓氬寲鑺傚锛涢噸缃寖鍥村湪绉疮鎰熶笌鍏钩鎬т箣闂磋蛋閽笣锛涢厤瀵规満鍒垛€斺€斾笅璧涘涓庤皝涓烘晫銆佸浣曞垎缁勨€斺€旀洿鏄喅瀹氫綋楠岃川閲忕殑鍏抽敭鍙橀噺銆傘€婁笁鍥借皨瀹氬ぉ涓嬨€嬬缉鐭禌瀛h妭濂忥紝鍔犲揩浜嗏€滈噸寮€涓€灞€鈥濈殑棰戠巼浠ョ淮鎸佹柊椴滄劅锛屼絾杩欎篃鏆撮湶浜嗘柊闂锛氳嫢鍖归厤璐ㄩ噺涓嶉珮銆侀暱鑽夋湡濉厖涓嶈冻锛屽揩閫熼噸缃弽鑰屽姞閫熷缇庣柌鍔炽€?*璧涘鍒舵槸涓€鍓傜寷鑽紝鍓傞噺闇€瑕佸弽澶嶈皟璇?*銆俓n +--- + +### 锛堜簩锛変骇鍝佹紨杩涜剦缁淺n +浠庛€婄巼鍦熶箣婊ㄣ€嬪埌銆婁笁鍥藉織銉绘垬鐣ョ増銆嬪啀鍒般€婁笁鍥借皨瀹氬ぉ涓嬨€嬶紝**杩欎釜鍝佺被浠庢潵娌℃湁杩囬瑕嗘€ч潻鍛斤紝閮芥槸娌跨潃涔嬪墠璇寸殑鍥涘ぇ鏍稿績璁捐涓€鐐圭偣鎵撶(浼樺寲**銆傛瘡涓€浠i兘鍦ㄨВ鍐充笂涓€浠g殑鑰侀棶棰橈紝鍚屾椂涔熶細甯﹀嚭鑷繁鐨勬柊楹荤儲銆俓n +- **鎴樼暐灞傛紨杩涳細璁╃┖闂村崥寮堟洿鏈夊眰娆?* + +鏃╂湡銆婄巼鍦熶箣婊ㄣ€嬩腑锛岀Щ鍔ㄦ潈鍜屽崰棰嗘潈鏄粦瀹氱殑锛岄儴闃熻蛋鍒板摢锛屾墦鍒板摢锛岄摵璺氨鏄竴鍒囥€傚悗鏉ョ殑浜у搧寮€濮嬪皢浜岃€呭垎绂伙細浣犲彲浠ヨ皟鍔ㄩ儴闃熷揩閫熻鍐涢€氳繃鐩熷弸棰嗗湴锛屼絾瑕佸崰棰嗕竴鍧楀湡鍦帮紝蹇呴』鍋滀笅鏉モ€滄墦鍦扳€濄€傝繖涓€鐪嬩技寰皬鐨勬敼鍔紝鍏跺疄鏋佸ぇ涓板瘜浜嗙┖闂存垬鐣ョ殑缁村害鈥斺€旇鍐涜矾绾夸笌鍗犻璁″垝鍙樻垚浜嗕袱閬撶嫭绔嬬殑鎬濊€冮锛屾垬鍦哄垏鍓层€侀鍦板琚€佺旱娣遍槻寰$瓑鎴樻湳鎵嶆湁浜嗘搷浣滅┖闂淬€傚彟涓€涓噸瑕佹柟鍚戞槸**涓汉鐩爣涓庤禌瀛g洰鏍囩殑鍒嗙**銆傝繃鍘荤帺瀹朵釜浜虹殑鎴愰暱璺緞鍜屽悓鐩熺殑璧涘杩涚▼楂樺害缁戝畾锛岀幇鍦ㄥ垯缁欎簡鏇村鈥滆嚜鎴戠帺娉曗€濈殑璁捐绌洪棿锛氫綘鍙互涓撴敞绉嶇敯銆佸彲浠ユ垚涓洪摵璺笓瀹躲€佸彲浠ヨ拷姹備釜浜烘垬鍔熸帓鍚嶏紝姣忕鐜╂硶閮芥湁瀵瑰簲鐨勬鍙嶉銆俓n +- **鎴樻枟灞傛紨杩涳細璁╃瓥鐣ヨ璇濓紝鑰岄潪鏁板瓧璇磋瘽** + +杩欎竴灞傜殑婕旇繘鏂瑰悜鏈€涓烘槑纭細**涓嶆柇鍘嬬缉绾暟鍊煎樊璺濈殑褰卞搷锛岃绛栫暐鍐崇瓥鐨勮川閲忔垚涓鸿儨璐熺殑鏈€缁堣鍒?*銆備粠銆婄巼鍦熶箣婊ㄣ€嬪缓绔嬪熀纭€鐨勫叺绉嶅厠鍒跺拰鎴樻硶妗嗘灦锛屽埌銆婁笁鍥藉織路鎴樼暐鐗堛€嬪湪鎶€鑳借仈鍔ㄣ€侀樀瀹规惌閰嶄笂鍋氬嚭娣卞害锛屽啀鍒般€婁笁鍥借皨瀹氬ぉ涓嬨€嬭繘涓€姝ユ墦纾ㄢ€斺€旀垬娉曞彂鍔ㄧ巼涓嶅啀鏄蹇戒笉瀹氱殑杩愭皵锛岃€岃璁捐鎴愮ǔ瀹氬彲棰勬湡鐨勬鐜囷紱骞虫皯鈥滅闃熲€濊涓诲姩濉戦€犲嚭鏉ワ紝涓嶆槸鏂借垗锛岃€屾槸淇濋殰鍏嬪埗閾炬潯瀹屾暣鎬х殑蹇呴渶鍝併€傛瘡涓€姝ラ兘鍦ㄥ己鍖栦竴涓俊鍙凤細**鎯虫竻妤氬啀鎵擄紝姣斿厖澶熼挶鍐嶆墦锛屾洿鏈夌敤**銆俓n +- **鑺傚灞傛紨杩涳細鏇村揩寰幆锛屾洿澶氬~鍏?* + +璧涘鑺傚鏁翠綋鍛堢缉鐭秼鍔裤€傝禌瀛h秺鐭紝鐜╁瓒婁笉瀹规槗闄峰叆闀跨嚎鐤插姵锛屼絾涔熸剰鍛崇潃鍐呭琚秷鑰楀緱鏇村揩銆備簬鏄骇鍝佸紑濮嬪湪鈥滃~鍏呪€濅笂鍋氭枃绔犫€斺€斿紩鍏ヨ亴涓氱郴缁熴€佸墽鏈満鍒躲€佽禌瀛i檺瀹氱帺娉曪紝鐢ㄦ洿澶氱瓥鐣ョ淮搴︽潵鎷夐暱鐜╁鐨勬湁鏁堟帰绱㈡湡銆傚尮閰嶆満鍒朵篃鍙樺緱鏇村叧閿細濡傛灉閰嶅璐ㄩ噺涓嶉珮锛岀缉鐭禌瀛e弽鑰屼細鍔犻€熷缇庣柌鍔筹紝鍥犱负鐜╁鍒氭墦瀹屼竴灞€鏃犺叮鐨勪粭锛岄┈涓婂張瑕侀潰瀵逛笅涓€灞€鏃犺叮鐨勪粭銆傛墍浠ヨ禌瀛h妭濂忕殑璋冩暣锛?*鏈川涓婃槸鎶婂帇鍔涗粠鈥滆禌瀛e唴鈥濊浆绉诲埌浜嗏€滆禌瀛i棿鈥?*锛屽鍖归厤绛栫暐鍜岄暱鑽夋湡杩愯惀鎻愬嚭浜嗘洿楂樼殑瑕佹眰銆俓n +--- + +### 锛堜笁锛夊叕骞崇瓥鐣ョ敓鎬乗n +鍏钩鎬ч渶瑕佷粠鍟嗕笟妯″紡銆佷环鍊煎垎閰嶅拰鐩爣缁戝畾涓変釜缁村害鍚屾鍙戝姏鐨勭簿瀵嗙郴缁熴€傚畠鐨勬牳蹇冧富寮犳槸锛?*璁╀笉鍚屽眰绾с€佷笉鍚屽亸濂界殑鐜╁锛岄兘鑳藉湪杩欏绯荤粺閲屾壘鍒拌嚜宸辩殑鑳滃埄璺緞鍜屽瓨鍦ㄤ环鍊?*銆俓n +- **鍟嗕笟妯″紡绔細浠樿垂鏈変笂闄愶紝绛栫暐鏃犱笂闄?* + +杩欎竴绔殑鍏抽敭璁捐鏄€?*鍚庡浼樺娍**鈥濓紝璧涘鍐咃紝鎵€鏈夌帺瀹剁殑绛夌骇涓婇檺銆佸叺鍔涜祫婧愬拰瑁呭鍩虹绾垮熀鏈竴鑷达紱鍗$墝鎴樺姏鍜屾垬娉曟敹鐩婂憟杈归檯閫掑噺锛岃秺寰€鍚庢蔼锛屾瘡澶氳姳涓€鍧楅挶鐨勫洖鎶ヨ秺灏忋€傚悓鏃讹紝**鍏嬪埗浣撶郴蹇呴』鈥滅ǔ瀹氬彲鐞嗚В鈥濓細鍏嬪埗閾炬潯娓呮櫚锛屽彂鍔ㄦ鐜囧彲淇?*锛岃鐜╁鐭ラ亾涓轰粈涔堣耽浜嗐€佷负浠€涔堣緭浜嗐€傚钩姘戔€滅闃熲€濈殑瀛樺湪涓嶆槸绂忓埄锛岃€屾槸鍏嬪埗浣撶郴鐨勫繀瑕佺粍鎴愰儴鍒嗭紝鏈変簡瀹冧滑锛屼粯璐圭帺瀹剁殑闃靛浼樺娍鎵嶈兘琚瓥鐣ュ弽鍒讹紝鍏嬪埗閾炬墠涓嶄細鍥犱负缂哄皯鏌愪竴鐜€屾柇瑁傘€傜敱姝?*涓嶅悓浠樿垂灞傜骇鐨勭帺瀹堕兘鏈夊畬鏁寸殑鍙備笌閾捐矾**銆俓n +- **浠峰€煎垎閰嶇锛氫笉姝竴绉嶆柟寮忔垚涓衡€滄湁鐢ㄧ殑浜衡€?* + +鎴樻枟涓嶆槸璐$尞鐨勫敮涓€褰㈠紡銆?*瀹冭璁′簡姝﹀媼鍜岃础鐚袱鏉¤揣甯侀摼璺細姝﹀媼鏉ヨ嚜鐩存帴鎴樻枟锛岃础鐚潵鑷摵璺€佸唴鏀裤€佽祫婧愯繍杈撶瓑鍗忓悓琛屼负**銆備袱鏉¢摼璺兘鑳藉厬鎹㈣禌瀛f牳蹇冨鍔憋紝閮借兘绉疮绀句氦澹版湜銆傝繖鎰忓懗鐫€涓嶆搮闀挎墦鏋剁殑鐜╁锛岄€氳繃閾鸿矾銆佸悗鍕ゃ€佹儏鎶ヤ竴鏍疯兘鎴愪负鍚岀洘涓嶅彲鎴栫己鐨勮鑹层€傝亴涓氱郴缁熷垯杩涗竴姝ユ妸杩欏閫昏緫鍒跺害鍖栤€斺€斿ぉ宸ラ摵璺€佸徃浠撳悲鐢般€佸浣愬琚紝姣忎釜鑱屼笟閮藉搴斾竴绉嶆槑纭殑鈥滄湁鐢ㄢ€濈殑鏂瑰紡锛岃鐜╁涓嶆槸鎸ゅ湪鍚屼竴鏍圭嫭鏈ㄦˉ涓婏紝鑰屾槸鍒嗗竷鍦ㄥ鏉″苟琛岃建閬撲笂銆俓n +- **鐩爣缁戝畾绔細璧㈣涓€璧疯耽锛岃緭涓嶈浣犱竴涓汉鎵?* + +涓汉鐩爣涓庨泦浣撶洰鏍囪寮虹粦瀹氾紝鍚岀洘鍗犻娲涢槼锛屼綘鎵嶈兘鎷垮埌闇镐笟濂栧姳锛涘悓鐩熺瓑绾ф彁鍗囷紝浣犳墠鑳借В閿佹洿澶氱鎶€銆備絾杩欏缁戝畾鏈変竴涓?*闅愭偅锛氬姡鍔挎柟鐨勪綋楠?*銆傚鏋滀綘鎵€鍦ㄧ殑鐩熻鎵撳穿浜嗭紝涓汉鍐嶅姫鍔涙槸涓嶆槸涔熸鏃犳剰涔夛紵鎵€浠ヨ繖閲岄渶瑕佷竴閬?*浣撻獙鍏滃簳鈥斺€斿叕骞崇殑濂栧姳鍒嗛厤鏈哄埗**銆傚嵆浣垮悓鐩熸暣浣撳浜庡姡鍔匡紝鍙涓汉绉瀬鍙傛垬銆侀〗寮洪槻瀹堬紝浠嶈兘鑾峰緱涓嶉敊鐨勪釜浜烘敹鐩婏紱鍚屾椂绯荤粺浼氬閫犫€滃鑳嗚嫳闆勨€濆紡鐨勫彊浜嬶紝璁╁湪閫嗗涓墦鍑轰寒鐪艰〃鐜扮殑鐜╁鑾峰緱鐙壒鐨勫瓨鍦ㄦ劅銆傝繖纭繚浜嗘瘡涓禌瀛e姣忎竴浣嶅弬涓庤€呴兘鏈夋剰涔夈€俓n +--- + +### 锛堝洓锛夊搧绫诲叡鎬т笌闅愭偅 + +鐜囧湡-Like鍝佺被鍙戝睍鍒颁竴瀹氶樁娈靛悗浼氭诞鐜扮殑缁撴瀯鎬х煕鐩俱€俓n +- **鍏钩涓庡晢涓氬寲鐨勬牴鏈煕鐩?* + +鍝佺被瓒婅拷姹傚叕骞筹紝绾暟鍊煎氨瓒婇毦鍞崠銆傚湪鍏钩鎴樻枟鐨勬鏋朵笅锛?*浠樿垂鐨勮竟闄呮敹鐩婅涓ユ牸鍘嬬缉锛岄珮浠樿垂鐜╁鐨勬姇鍏ヤ骇鍑烘瘮瓒婃潵瓒婁綆**銆傝繖鍌敓浜嗕竴绯诲垪杩為攣鍙嶅簲锛氫拱涓€涓垚鍝佸彿姣斿厖鍊煎吇鍙峰垝绠楀緱澶氾紝璧勯噾娴佸悜浜嗚处鍙蜂氦鏄撳競鍦鸿€岄潪瀹樻柟鍟嗗簵锛涚帺瀹堕€氳繃鈥滄帶绾⑩€濆帇浣庢垬鍔涜瘎鍒嗗幓閮婂尯韬鸿耽锛屽洜涓洪珮寮哄害瀵规垬鍜屼綆寮哄害瀵规垬鐨勬渶缁堝鍔卞嚑涔庝竴鏍凤紝閭d负浠€涔堣鑺遍挶鎵剧姜鍙椼€傚畼鏂圭殑鏁板瓧鍞崠绌洪棿琚笉鏂尋鍘嬶紝鑰屽崠鐨偆銆佸崠澶栬杩欑被鏇夸唬鍙樼幇鏂瑰紡鐨勫睍绀哄満鏅張鍗佸垎鏈夐檺銆?*杩欐槸鍟嗕笟妯″紡涓庡叕骞崇敓鎬佷箣闂存渶鏍规湰鐨勯敊浣嶁€斺€斾綘瓒婂厬鐜扳€滃叕骞斥€濈殑鎵胯锛屽氨瓒婇毦鍥炵瓟鈥滀负浠€涔堣鍏呴挶鈥濊繖涓棶棰?*銆俓n +- **绛栫暐闂ㄦ涓庡ぇ浼楀寲鐨勫紶鍔?* + +**涓板瘜鐨勭瓥鐣ョ淮搴︽槸鑰佺帺瀹剁殑涔愯叮鏉ユ簮锛屽嵈鏄柊鐜╁鐨勭涓€閬撻珮澧欍€傚厠鍒朵綋绯汇€佹垬娉曡仈鍔ㄣ€侀樀瀹规惌閰嶃€佹垬鍦烘椂鏈猴紝姣忎竴椤归兘闇€瑕佸ぇ閲忕殑瀛︿範鎴愭湰**銆傛柊鐜╁杩涘叆鍚庡緢瀹规槗闄峰叆璁ょ煡杩囪浇锛氫笉鐭ラ亾璇ユ€庝箞閰嶅皢銆佺湅涓嶆噦涓轰粈涔堟墦杈撲簡銆佹敾鐣ュ垰瀛︿細灏卞洜鐗堟湰鏇存柊鑰屽け鏁堛€備笌姝ゅ悓鏃讹紝鍑忚礋璁捐铏界劧瑙f斁浜嗘搷浣滐紝涔熻鐜╁鏇村揩鍦版秷鑰楁帀浜嗚禌瀛g殑鈥滄湁鏁堝唴瀹光€濓紝鏃╂棭杩涘叆闀胯崏鏈熸棤浜嬪彲鍋氥€?*澧炲姞浜嗘柊鐢ㄦ埛鐨勪笂鎵嬮棬妲涳紝闀胯崏鏋嚗璁╄€佷汉寰€澶栨祦锛屽叡鍚屾瀯鎴愪簡鐣欏瓨鐨勫弻閲嶅帇鍔?*銆?*鍝佺被瑕佽蛋鍚戞洿澶ц妯$殑澶т紬鍖栵紝灏卞繀椤昏В鍐宠繖涓€滄繁浜嗕笉浜叉皯锛屾祬浜嗕笉鎶ゅ煄鈥濈殑涓ら毦**銆俓n +- 鐢熸€佹壙杞藉姏涓庡閲忔垚鏈殑澶辫  + +鐜囧湡-Like闇€瑕佽冻澶熺殑浜哄彛鍩烘暟鎵嶈兘褰㈡垚鍋ュ悍鐨勫鎶楀垎灞傘€傚鏋滃閲忎笉瓒炽€佸崟鏈嶆椿璺冪帺瀹朵笉澶燂紝**浼氬嚭鐜板己鐨勭洘娌℃湁瀵规墜锛屽急鐨勭洘娌℃湁甯屾湜锛屼腑闂村眰鐨勭ぞ浜ゅ叧绯诲洜涓轰汉鏁扮█鐤忚€岄毦浠ュ缓绔?*銆傛墦鏋舵墦涓嶈捣鏉ワ紝澶栦氦娌℃剰涔夛紝绠$悊娌″姩鍔涳紝**鏁翠釜鐢熸€佷粠瀵规姉閫€鍖栨垚浜嗗崟鏈虹鐢?*銆傝€屽閲忔槸鏈夋垚鏈殑锛?*褰撲拱閲忎环鏍煎拰鍗曟湇鐢熸€佸惎鍔ㄦ墍闇€鐨勬渶浣庝汉鍙i棬妲涗箣闂村嚭鐜板€掓寕锛屼骇鍝佺殑鎵╁紶灏变細闄峰叆鐡堕**銆傝繖涓嶆槸鐜╂硶璁捐鐨勯棶棰橈紝鑰屾槸**鍟嗕笟妯″瀷涓庡搧绫荤壒鎬т箣闂寸殑绯荤粺鎬х煕鐩?*銆俓n + +**鍏钩鎴樻枟鎶戝埗浜嗘暟鍊间粯璐癸紝闄嶈倽鍑忚礋鎷変綆浜嗗洟鎺ф垚鏈?*銆?*瑙e喅闂鐨勫叧閿笉鏄皝鍫垫紡娲烇紝鑰屾槸閲嶆瀯婵€鍔?*銆傗€滃啝鍐涙湇鈥濈殑鎬濊矾鍊煎緱鍊熼壌锛?*涓嶉€肩帺瀹舵墦鏋讹紝鑰屾槸璁╂墦鏋跺彉寰楀垝绠楋紝鎶婇浂鍜屽崥寮堟壄杞负姝e悜绔炲悎**銆俓n闄嶄綆绛栫暐闂ㄦ璁╂洿澶氫汉杩涘緱鏉ワ紝鎶婄鐞嗚€呭拰杈呭姪瑙掕壊鐨勯殣褰㈣础鐚樉鎬у寲銆?*鍑忚礋鐨勭洰鏍囨槸涓轰簡璁╂父鎴忓湪鏇村弸濂界殑鍚屾椂瀹堜綇鍏钩涓庡崥寮堢殑搴曠嚎**銆俓n diff --git a/docs/doc_22_Document_22.md b/docs/doc_22_Document_22.md new file mode 100644 index 0000000..f8ef4a3 --- /dev/null +++ b/docs/doc_22_Document_22.md @@ -0,0 +1,29 @@ +# 2026.5.9-鏃ユ姤-寮犲鎸痋n +## 宸ヤ綔鍐呭姒傝堪 + +1銆侀€氳繃ollama鍦℅UP鏈嶅姟鍣ㄤ笂gemma-4-E4B 妯″瀷 + +2銆侀€氳繃UI-TARS鑷姩璺戞父鎴廫n +--- + +## 涓€銆乁I-TARS锛歕n +UI-TARS Desktop 鏄敱瀛楄妭璺冲姩寮€婧愮殑涓€娆炬闈I鏅鸿兘浣撳簲鐢紝瀹冭兘璁╃敤鎴烽€氳繃鑷劧璇█鏉ョ洿鎺ユ帶鍒剁數鑴戝畬鎴愬悇绉嶆搷浣溿€俓n + **鏍稿績鍔熻兘浜偣** + +- 绾瑙夐┍鍔細涓庝紶缁熶緷璧栧浐瀹氭帶浠禝D鐨勮嚜鍔ㄥ寲宸ュ叿涓嶅悓锛屽畠鍍忎汉涓€鏍烽€氳繃瑙嗚璇嗗埆鐣岄潰鍏冪礌锛屽嵆浣跨晫闈㈠竷灞€鍙戠敓鏀瑰彉涔熻兘鑷€傚簲銆俓n- 鑷劧璇█浜や簰锛氭棤闇€瀛︿範浠讳綍浠g爜鎴栬剼鏈紝浣犲彧闇€鐩存帴璇村嚭鎴栬緭鍏ヤ綘鐨勯渶姹傦紝渚嬪鈥滃府鎴戞妸妗岄潰鏁寸悊涓€涓嬧€濄€俓n- 寮哄ぇ鐨勫妯℃€佺悊瑙o細涓嶄粎鑳借瘑鍒枃瀛楀拰鎸夐挳锛岃繕鑳界悊瑙e厓绱犻棿鐨勪笂涓嬫枃鍜岀┖闂村叧绯汇€俓n- 瀹炴椂鍔ㄦ€佷氦浜掞細鑳藉疄鏃剁洃鎺у苟鍝嶅簲灞忓箷鐨勫姩鎬佸彉鍖栵紝渚嬪寮圭獥鐨勭獊鐒跺嚭鐜般€俓n- 鏈湴杩愯涓庤法骞冲彴锛氭敮鎸佸湪 Windows 鍜?macOS 涓婃湰鍦版墽琛屼换鍔★紝淇濋殰鏁版嵁闅愮锛屽苟閫氳繃缁熶竴鐨勫姩浣滅┖闂村湪涓嶅悓搴旂敤闂存棤缂濆垏鎹€俓n- 鍏ㄩ潰鐜鏁村悎锛氶櫎浜嗗熀鏈殑妗岄潰鎿嶄綔锛岃繕鑳戒笌娴忚鍣ㄣ€佸懡浠よ缁堢鍜屾枃浠剁郴缁熸繁搴︿氦浜掋€俓n +寮€婧愬湴鍧€锛歔UI-TARS-desktop](https://github.com/bytedance/UI-TARS-desktop) + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=NGI2MDlmZjM1MzQwMGE2MjIzZWZjN2ZmZTFjOTg3YWZfMDMxZTI0Y2M5N2EyNDVjODYwMzM1ZmJiODAwNWZkZjVfSUQ6NzYzNzkwOTI1Mzg3MjkxMzYwMV8xNzc5MTc2MTI0OjE3NzkxNzk3MjRfVjM) + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=ZmU3ZTI5YmM0YWNmZWQ3MTM3ODQ0MmU0YzM0NWVlYzFfYTc3YjQyNjVhM2Q1YzY0ZjgwYmE2NWM4MDE5MDk2MDdfSUQ6NzYzNzkwOTM1MTg0MzQ0OTgyNV8xNzc5MTc2MTI0OjE3NzkxNzk3MjRfVjM) + + +鏈湴璺戜笉鍔ㄥ甫鍥惧儚璇嗗埆鐨勬ā鍨嬶紝鍏堟槸浣跨敤鐨凲wen鐨勬ā鍨婣PI锛屼絾鏄粬涓夊洓绉掓墠鍙嶅簲涓€娆★紝UI-TARS鐨勫ソ澶勬槸鍙互鐩存帴鎿嶄綔鎴戠殑鐢佃剳锛屾瘮濡傛ā鎷熼敭鐩榃SAD璺熼紶鏍囩偣鍑讳簨浠讹紝杩欐牱鍙鐢佃剳鑳借窇鐨勬父鎴忎粬灏辫兘鎿嶄綔銆? +浠栬兘椤哄埄鐨勮窇璧锋潵浜嗭紝浣嗘槸闇€瑕佸ソ涔呮墠璺戣繘涓嬩竴鍏炽€傝繖鏍峰お鎱篃澶儳Token浜嗭紝鍐嶈瘯璇曢€氳繃GPU鏈嶅姟鍣ㄨ窇妯″瀷銆俓n + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=MzMzOWU0NWRiYjNiZGMyZWE2MTIwYjQyMWQ0NTFmOWFfZDgzMzFmMDhiNTg0NzYxY2U5ODI1ODU3MTE0NDM1MmNfSUQ6NzYzNzkzNDY3OTMwNzQ4ODIyNF8xNzc5MTc2MTI0OjE3NzkxNzk3MjRfVjM) + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=MWJmOTljYTM1ODY2OTI1NTIxOWU4MmU5YzVmMTc5NjNfZGI1MDUyMDRjNDlkMjE0ZDE0MWNhZWQzNzBmNDg3NmRfSUQ6NzYzNzkzODgyODI0OTk1OTYyM18xNzc5MTc2MTI0OjE3NzkxNzk3MjRfVjM) + + +棣栧厛鎴戜娇鐢ㄧ殑鏄疧llama鏉ヨ窇鏈湴妯″瀷锛屼絾鏄亣鍒颁竴涓棶棰橈紝Ollama涓嶆敮鎸丟emma 4鏈€鏂扮殑mmproj锛堣瑙夋姇褰憋級锛岃繖涓绛夊悗闈llama鍚庢湡鍏煎銆傚悗闈㈡崲鎴愰偅llama-server鏉ヨ窇Gemma妯″瀷锛岃兘鎴愬姛璺戣捣鏉ヤ簡锛屽弽搴斾篃姣擰wen妯″瀷鍙嶅簲蹇簡涓嶅皯锛屽ぇ姒備竴涓ょ灏辨湁涓€娆″弽棣堜簡锛屼絾鎴戜娇鐢ㄧ殑鏄疓emma 4 7B鍙傛暟鐨勬ā鍨嬶紝鏁翠綋鎰熻娌℃湁浣跨敤Qwen閭d箞鐨勮仾鏄庯紝鍚庢湡鐪嬬湅鏈夋病鏈夊叾浠栨洿閫傜敤鐨勬ā鍨嬫垨鑰呴€氳繃寰皟鐨勬墜娈碉紝鏃㈣兘淇濊瘉閫熷害涔熻兘淇濊瘉璐ㄩ噺銆俓n diff --git a/docs/doc_23_Document_23.md b/docs/doc_23_Document_23.md new file mode 100644 index 0000000..86d226b --- /dev/null +++ b/docs/doc_23_Document_23.md @@ -0,0 +1,72 @@ +# 2026.5.15-鏃ユ姤-寮犲鎸痋n +## 宸ヤ綔鍐呭姒傝堪 + +1銆佸涔犲苟瀹炶返鍒朵綔鐭ヨ瘑搴揬n +--- + + +鏄ㄦ棩鏃佸惉浜嗗崈灞遍」鐩粍鍚屼簨鍏充簬鐭ヨ瘑搴撶殑鍒嗕韩锛屾敹鑾烽涓般€傝鍒掑€熷姪 Cursor 宸ュ叿鍔ㄦ墜寮€鍙戜竴娆剧煡璇嗗簱搴旂敤锛屽湪瀹炶返涓悊瑙g煡璇嗗簱鐨勬瀯寤轰笌搴旂敤娴佺▼銆俓n + +## 涓€銆丷AG 绯荤粺绠€杩癨n +RAG 鍦ㄧ煡璇嗗簱涓殑浣滅敤鏄細灏嗗ぇ璇█妯″瀷涓庡閮ㄧ煡璇嗘绱㈢浉缁撳悎锛屼娇鐭ヨ瘑搴撲粠琚姩瀛樺偍鍗囩骇涓鸿兘澶熶富鍔ㄧ悊瑙i棶棰樸€佸疄鏃跺彫鍥炵浉鍏充俊鎭苟鐢熸垚鏈夋嵁鍙緷鐨勭簿鍑嗙瓟妗堢殑鏅鸿兘绯荤粺銆俓n +**RAG锛圧etrieval-Augmented Generation锛屾绱㈠寮虹敓鎴愶級**鏄竴绉嶈澶фā鍨嬪湪鍥炵瓟闂鍓嶅厛浠庡閮ㄧ煡璇嗗簱妫€绱㈢浉鍏充俊鎭殑鏋舵瀯銆傚叾鏍稿績娴佺▼涓猴細鐢ㄦ埛鎻愰棶 鈫?浠庣煡璇嗗簱妫€绱㈢浉鍏冲唴瀹?鈫?灏嗛棶棰樺拰妫€绱㈢粨鏋滄嫾鎺ユ垚 Prompt 鈫?澶фā鍨嬬敓鎴愮瓟妗堛€俓n +RAG 鐨勬牳蹇冧环鍊煎湪浜庤В鍐冲ぇ妯″瀷鐨勪袱涓眬闄愶細鐭ヨ瘑鎴鏃ユ湡闂鍜屽够瑙夐棶棰樸€傞€氳繃澶栨寕鐭ヨ瘑搴擄紝妯″瀷鏃犻渶閲嶆柊璁粌灏辫兘璁块棶鏈€鏂版垨绉佹湁鐨勭煡璇嗭紝涓斿洖绛旀湁鎹彲鏌ャ€俓n +## 浜屻€丷AG 绯荤粺缁勬垚 + +1. **鏁版嵁鎽勫彇灞?*锛氭敮鎸佸绉嶆牸寮忔枃妗g殑瑙f瀽鍜屽姞杞斤紙PDF銆丮arkdown銆佺綉椤电瓑锛夈€俓n2. **鏂囨湰鍒囩墖**锛氬皢闀挎枃妗f寜璇箟鎴栭暱搴﹀垏鎴愬皬鍧楋紝淇濊瘉姣忓潡淇℃伅瀹屾暣涓斾究浜庢绱€俓n3. **Embedding 妯″瀷**锛氬皢鏂囨湰鍧楄浆鎹负鍚戦噺锛屽疄鐜拌涔夌骇鐞嗚В銆俓n4. **鍚戦噺鐭ヨ瘑搴?*锛氬瓨鍌ㄥ拰妫€绱?Embedding 鍚戦噺锛屾敮鎸佽涔夋悳绱€俓n5. **鍏ㄦ枃妫€绱㈠紩鎿?*锛氬熀浜庡叧閿瘝鍖归厤鐨勬悳绱㈣兘鍔涳紝琛ヨ冻鍚戦噺妫€绱㈢殑鐭澘銆俓n6. **澶ц瑷€妯″瀷**锛氬熀浜庢绱㈢粨鏋滅敓鎴愭渶缁堝洖绛斻€俓n7. **缂栨帓灞?*锛氫覆鑱旀绱㈠拰鐢熸垚娴佺▼锛屽鐞嗕氦浜掗€昏緫銆俓n +### (涓€) Embedding 妯″瀷 + +**鑳藉皢鏂囨湰銆佸浘鐗囩瓑闈炵粨鏋勫寲鏁版嵁杞崲鎴愬浐瀹氶暱搴︽暟瀛楀悜閲忥紙涓€涓叉暟瀛楋級鐨勭缁忕綉缁滄ā鍨?*銆傝繖涓悜閲忓彲浠ョ湅浣滄暟鎹殑鈥滆涔夊潗鏍団€濓紝鎰忔€濈浉杩戠殑鏂囨湰锛屽叾鍚戦噺鍦ㄦ暟瀛︾┖闂翠腑鐨勮窛绂讳篃鎺ヨ繎銆俓n +**鑳藉共浠€涔?* + +1. **璇箟鎼滅储**锛氫笉渚濊禆鍏抽敭璇嶅瓧闈㈠尮閰嶏紝鐢ㄦ埛杈撳叆鈥滄垜鎯冲悆姘存灉鈥濊兘鎵惧埌鈥滄垜鍚冭嫻鏋溾€濈殑绗旇銆俓n2. **鏂囨湰鑱氱被涓庡垎绫?*锛氳嚜鍔ㄥ皢鐩镐技鍐呭鐨勭瑪璁板綊鍒颁竴璧枫€俓n3. **浣滀负澶фā鍨嬬殑杈撳叆鍩虹**锛氭墍鏈夊ぇ璇█妯″瀷鍐呴儴閮藉湪浣跨敤 Embedding 鏉ョ悊瑙f枃瀛楋紝RAG 涓绱㈠嚭鐨勬枃鏈潡鏈€缁堜篃浠ユ褰㈠紡鍙備笌鍚庣画鐢熸垚銆俓n +**鐭ヨ瘑搴撲腑鐨勪綔鐢?* + +Embedding 妯″瀷璐熻矗灏嗙瑪璁板唴瀹瑰拰鐢ㄦ埛闂杞寲涓哄悜閲忥紝瀛樺叆 Chroma 鍚戦噺鏁版嵁搴撱€傜敤鎴锋彁闂椂锛岀郴缁熺敤鍚屼竴妯″瀷灏嗛棶棰樺悜閲忓寲锛屽啀鐢?Chroma 閫氳繃鍚戦噺璺濈妫€绱㈠嚭鏈€鐩稿叧鐨勭瑪璁扮墖娈碉紝鏈€缁堜氦缁欏ぇ妯″瀷鐢熸垚绛旀銆傚畠鏄暣涓涔夋绱㈢幆鑺傜殑鏍稿績寮曟搸銆俓n +### (浜? 鍚戦噺鐭ヨ瘑搴擄紙璇箟鎼滅储锛塡n +**鑳藉皢鏂囨湰銆佸浘鐗囩瓑鏁版嵁杞崲鎴愮殑鍚戦噺瀛樺偍璧锋潵锛屽苟鎻愪緵楂樻晥鐩镐技鍚戦噺妫€绱㈣兘鍔涚殑鏁版嵁搴撶郴缁?*銆備笌浼犵粺鐨勭簿鍑嗗尮閰嶆煡璇笉鍚岋紝瀹冮€氳繃璁$畻鍚戦噺涔嬮棿鐨勮窛绂绘潵瀵绘壘璇箟涓婃渶鐩歌繎鐨勫唴瀹广€俓n +**鑳藉共浠€涔?* + +1. **璇箟鎼滅储**锛氭牴鎹棶棰樺惈涔夋壘鍒扮浉鍏虫枃妗o紝鍗充娇瀛楅潰瀹屽叏涓嶅悓鐨勨€滄按鏋溾€濆拰鈥滆嫻鏋溾€濅篃鑳界浉浜掑懡涓€俓n2. **鎺ㄨ崘涓庡幓閲?*锛氬熀浜庡悜閲忚窛绂诲垽鏂唴瀹圭浉浼煎害锛屽彲鐢ㄤ簬鐩稿叧鎺ㄨ崘鎴栭噸澶嶅唴瀹硅瘑鍒€俓n3. **澶氭ā鎬佹绱?*锛氭敮鎸佷互鍥炬悳鍥俱€佷互鏂囨悳鍥剧瓑锛屽洜涓轰笉鍚屾ā鎬佺殑鏁版嵁鍙互鏄犲皠鍒板悓涓€鍚戦噺绌洪棿銆俓n4. **鏀拺澶фā鍨嬭蹇?*锛氫负 RAG 绯荤粺鎻愪緵澶栭儴鐭ヨ瘑瀛樺偍锛屼娇澶фā鍨嬭兘鈥滃洖蹇嗏€濊捣鏈缁冭繃鐨勭鏈夋垨鏈€鏂版暟鎹€俓n +**鐭ヨ瘑搴撲腑鐨勪綔鐢?* + +Embedding 妯″瀷灏嗙瑪璁拌浆鎹负鍚戦噺鍚庡瓨鍏ュ悜閲忓簱銆傜敤鎴锋彁闂椂锛岄棶棰樺悓鏍疯浆涓哄悜閲忥紝鐢卞悜閲忓簱蹇€熸壘鍑轰笌涔嬭窛绂绘渶杩戠殑绗旇鐗囨锛屽疄鐜板熀浜庤涔夌殑鐩稿叧鍐呭鍙洖銆俓n +### (涓? 鍏ㄦ枃妫€绱n +**涓€绉嶅熀浜庡叧閿瘝鍜岃瘝姹囧尮閰嶇殑鎼滅储鎶€鏈紝閫氳繃鍊掓帓绱㈠紩蹇€熷畾浣嶅寘鍚寚瀹氳瘝璇殑鏂囨。**銆傚畠鍏虫敞鐨勬槸鏂囨湰涓槸鍚﹀嚭鐜般€佸嚭鐜颁簡澶氬皯娆℃煡璇㈣瘝锛屼互鍙婅瘝鐨勭簿纭尮閰嶅叧绯汇€俓n +**鑳藉共浠€涔?* + +1. **绮剧‘鍛戒腑**锛氭悳绱㈢壒瀹氭湳璇紙濡?IP 鍦板潃銆佸嚱鏁板悕銆侀敊璇爜锛夋椂鑳藉噯纭壘鍒版墍鏈夊寘鍚璇嶇殑鏂囨。銆俓n2. **缁撴瀯鍖栨煡璇?*锛氭敮鎸佸竷灏旀搷浣溿€佺煭璇尮閰嶃€佸墠缂€鎼滅储銆佹嫾鍐欏閿欑瓑绮剧‘鎺у埗銆俓n3. **鍙В閲婃帓搴?*锛氬熀浜庤瘝棰戙€佷綅缃瓑纭寚鏍囨帓搴忥紝缁撴灉纭畾鎬у己锛岀敤鎴疯兘棰勫垽鍝簺鏂囨。浼氭帓鍦ㄥ墠鍒椼€俓n4. **杞婚噺鏄撶淮鎶?*锛氬儚 MeiliSearch銆丼QLite FTS5 绛夊叏鏂囧紩鎿庨儴缃茬畝鍗曪紝璧勬簮鍗犵敤浣庯紝閫傚悎蹇€熼泦鎴愩€俓n +**鍦ㄧ煡璇嗗簱椤圭洰涓殑浣滅敤** + +灏嗙瑪璁板唴瀹瑰悓姝ヨ嚦鍏ㄦ枃绱㈠紩銆傚綋鐢ㄦ埛鎻愰棶鏃讹紝鍚屾椂鎵ц鍏抽敭璇嶆悳绱紝涓庡悜閲忔悳绱㈢粨鏋滃悎骞跺幓閲嶏紝寮ヨˉ璇箟鎼滅储鍦ㄧ簿纭湳璇笂鐨勪笉瓒筹紝褰㈡垚鈥滆涔夌悊瑙?+ 绮剧‘鍛戒腑鈥濈殑娣峰悎妫€绱㈣兘鍔涖€俓n +### (鍥? 璇箟鎼滅储涓庡叏鏂囨绱㈠悎骞朵笂涓嬫枃 + +鍘婚噸銆佷紭閫夈€佹暣鐞嗗嚭涓€浠介珮璐ㄩ噺涓斾笉鍐椾綑鐨勫弬鑰冧笂涓嬫枃锛屼緵澶фā鍨嬬敓鎴愮簿鍑嗙瓟妗堛€俓n +浜屻€佸悎骞朵笂涓嬫枃鐨勫叧閿楠n +1. **鍘婚噸** +涓ょ妫€绱㈠彲鑳藉懡涓悓涓€鏉$瑪璁帮紝棣栧厛鎸夌瑪璁板敮涓€鏍囪瘑锛圛D锛夎繘琛屽幓閲嶏紝**鐣欎俊鎭洿瀹屾暣鐨勯偅涓€浠?*锛岄伩鍏嶅悓涓€鍐呭閲嶅鍑虹幇鍗犵敤瀹濊吹鐨勪笂涓嬫枃绐楀彛銆俓n2. **铻嶅悎鎺掑簭** +灏嗚涔夋绱㈠拰鍏抽敭璇嶆绱㈢殑缁撴灉锛屾寜瀹冧滑鍚勮嚜鐨勯噸瑕佺▼搴﹂噸鏂扮患鍚堟帓搴忥紝褰㈡垚涓€涓叏灞€浼樺厛绾э紝纭繚鏈€鐩稿叧鐨勫唴瀹规帓鍦ㄥ墠闈€俓n3. **鎴柇涓庣粍鍚?* +鏍规嵁澶фā鍨嬬殑涓婁笅鏂囬暱搴﹂檺鍒讹紝瀵规帓搴忓悗鐨勭墖娈佃繘琛岄€傚綋鎴柇锛屾寜鈥滄爣棰?+ 鍐呭鎽樿鈥濇牸寮忔嫾鎺ユ垚缁撴瀯鍖栫殑鍙傝€冩枃妗e潡銆俓n +| 鍦烘櫙 | 璇箟妫€绱㈣兘鍔?| 鍏ㄦ枃妫€绱㈣兘鍔?| 鏈€浣虫柟妗?| +|-|-|-|-| +| 鍚屼箟璇?妯$硦鎰忓浘锛堟按鏋溾啋鑻规灉锛?| 寮?| 寮?| 璇箟 | +| 绮剧‘鎶€鏈湳璇€佷唬鐮併€両P | 寮?| 寮?| 鍏ㄦ枃 | +| 闀挎枃妗d腑鐨勭粏鑺?| 涓?| 寮?| 鍏ㄦ枃 + 璇箟 | +| 鎺掑簭鐨勭‘瀹氭€э紙瑕佹壘鍖呭惈鏌愪釜璇嶇殑锛?| 涓嶇ǔ瀹?| 绋冲畾 | 鍏ㄦ枃 | + + + + + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=OGJmMTI5MTFmZDYwODJjZGUyNjZhNmVlY2U3ZDYwYzdfYjE4M2IzOTg2NGY2YzY1ODBiYTcwNDVjN2MxNDc0ZGVfSUQ6NzY0MDA4MTU1NDEzOTcxMjcyNF8xNzc5MTc2MTI1OjE3NzkxNzk3MjVfVjM) + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=YTRhMmNiYmE4YmZlYzE5MGE3ZWM3MTEzMTAyYzE4YjBfMDc5YWU5YTQ1NWRjM2ZmNDBjNzhkMGNlYjhkY2FjNGNfSUQ6NzY0MDA3OTEwNTE2OTc4ODEyMl8xNzc5MTc2MTI1OjE3NzkxNzk3MjVfVjM) + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=ODk4ZmE3ZmFjNzEyZjIwN2Y2OGI4OTNkODY0NTY4MTNfZjRiZDVlOTExMzY2ZmZiNjQ2NDRhNzJiYTdkNWIxYjNfSUQ6NzY0MDA4MjIzOTE1NTExMjkxNl8xNzc5MTc2MTI1OjE3NzkxNzk3MjVfVjM) + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=N2Y5YTNkZDU5MTdmMzRjOTFjMzA0OGExZTdiOWVhNGNfN2ZiNDkxZTg4OTM3ZjEwZmYyNDIyNjkwZDNjYzQxOGFfSUQ6NzY0MDA3OTIwNjI5NjI3NjE4OF8xNzc5MTc2MTI1OjE3NzkxNzk3MjVfVjM) + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=NWNhYzkxZWYzOGEzMDBiNTUxNzcwMzA3MmRkNDgyYTZfZTE2NzUxMmZmOGQyMjViYTJkNTRhYmY0NDc2YjVjYjFfSUQ6NzY0MDA4MTY4OTM0MzExODUzMV8xNzc5MTc2MTI1OjE3NzkxNzk3MjVfVjM) + + +鎴戣寰楋紝鏈潵鎶€鏈煡璇嗕綋绯婚噷锛屽箍搴﹀彲鑳芥瘮娣卞害閲嶈寰楀銆傝兘鏇村揩鍦颁簡瑙f渶鏂扮殑 AI 鍙婄浉鍏崇煡璇嗭紝蹇€熶綋浼氥€佸揩閫熷疄楠岋紝鏇村揩鍦版妸瀹冪撼鍏ヨ嚜宸辩殑鎶€鑳戒綋绯汇€傝櫧鐒惰繕鏈夊緢澶氶鍩熸繁搴︿緷鐒朵笉鍙浛浠o紝浣嗗湪澶ч噺鈥滀腑闂村湴甯︹€濈殑寮€鍙戝伐浣滀笂锛岃交閲忋€佸揩閫熴€佸箍瑕嗙洊姝e湪鎴愪负鏂扮殑鏍稿績绔炰簤鍔涖€俓n diff --git a/docs/doc_24_Document_24.md b/docs/doc_24_Document_24.md new file mode 100644 index 0000000..2725c2c --- /dev/null +++ b/docs/doc_24_Document_24.md @@ -0,0 +1,28 @@ +# 2026.5.12-鏃ユ姤-寮犲鎸痋n +## 宸ヤ綔鍐呭姒傝堪 + +1銆佺户缁暣鐞嗕箣鍓嶅涔犳暣鐞嗙殑Agent + +--- + +### 涓€銆丄gent Team锛堟櫤鑳藉瑙掕壊鍗忎綔锛塡n +**灏嗗鏉備换鍔℃寜鈥滃厛璋佸仛銆佸啀璋佸仛鈥濈殑娴佺▼鎷嗗垎涓哄涓樁娈碉紝绯荤粺鎸夐『搴忚皟搴︿笉鍚屸€滆鑹测€濆悇璐熻矗涓€娈碉紝鏈€缁堜覆鑱斿悎鎴愬畬鏁寸粨鏋溿€傞€傚悎鐮旂┒+钀藉湴銆佸姝ラ娴佹按绾跨瓑闇€瑕佷笉鍚屼笓闀夸覆鑱旂殑鍦烘櫙銆?* + +- 姣忎釜闃舵浣跨敤璐村悎浠诲姟鐨勬寚浠ょ害鏉熸ā鍨嬶紝閬垮厤鈥滀竴鎶婃姄鈥濆鑷寸殑姝ラ閬楁紡鎴栭鏍兼贩涔便€俓n- 涓婁竴闃舵鐨勮緭鍑轰綔涓轰笅涓€闃舵鐨勮緭鍏ワ紝閫昏緫閾捐矾鏇存竻鏅般€俓n- 瀵逛娇鐢ㄨ€呰€岃█浠嶆槸涓€娆℃彁闂紝涓棿瑙掕壊鍗忎綔鐢辩郴缁熻嚜鍔ㄧ紪鎺掋€俓n- 涓讳細璇濅腑鍏堝垽瀹氭槸鍚﹂渶瑕佺粍闃熷強鍒嗙粍鏂瑰紡锛岄€氳繃鍚庣敱鍐呴儴璋冨害鍣ㄦ寜鎴愬憳鍒楄〃渚濇鎵ц锛岀劧鍚庝富agent杩涜鏈€缁堢殑缁熶竴姹囨€汇€俓n +### 浜屻€丼ub Agent锛堝瓙浠g悊锛塡n +**鍦ㄤ富瀵硅瘽澶栧崟鐙媺璧蜂竴鏉″共鍑€涓婁笅鏂囨墽琛屽皬鍨嬩笓椤逛换鍔★紝瀹屾垚鍚庡皢缁撴瀯鍖栫粨鏋滆繑鍥炵粰涓?Agent锛屼富Agent涓婁笅鏂囦笉浼氳涓棿闀胯繃绋嬫墍褰卞搷銆?* + +- 鐢ㄤ簬闅旂瀛愪换鍔°€佹帶鍒舵鏁颁笌杈撳嚭闀垮害锛岄伩鍏嶄富浼氳瘽涓殑宸ュ叿璋冪敤鍜屼腑闂磋崏绋垮紕涔变笂涓嬫枃銆俓n- 涓诲璇濅繚鎸佹竻鐖斤紱瀛愪换鍔″け璐ユ垨璺戝亸鏃跺奖鍝嶈寖鍥存槗浜庢敹鏁涳紝閫傚悎鎺㈣矾銆佷笓椤瑰皬娲汇€俓n- 閫氳繃宸ュ叿瑙﹀彂锛氫互鐙珛閰嶇疆鍓湰鍚姩涓存椂 Agent锛屾墽琛屽畬姣曞悗灏嗘枃鏈粨鏋滀氦鍥炰富娴佺▼銆俓n +### 涓夈€乀UI锛堢粓绔噷鐨勮亰澶╃晫闈級 + +**鍦ㄥ懡浠よ涓墦寮€鍏ㄥ睆缁堢鐣岄潰杩涜瀵硅瘽锛屾浛浠i€愯婊氬姩鐨勬棩蹇楀紡浜や簰銆?* + +- 閽堝闀垮璇濅紭鍖栧尯鍩熷竷灞€涓庢粴鍔紝瀵归暱鍥炲鍜岃〃鏍肩被鍐呭鍋氫簡灞曠ず閫傞厤銆俓n- 鏈湴銆佽交閲忋€佷笉渚濊禆娴忚鍣紝鍦ㄦ湇鍔″櫒鎴?SSH 鐜涓嬩篃鑳借垝閫傛煡鐪嬪璇濅笌妯″瀷杈撳嚭銆俓n- 鍩轰簬缁堢 UI 搴撳疄鐜板竷灞€涓庢覆鏌擄紝涓撻棬澶勭悊 Markdown 琛ㄦ牸銆佹崲琛屽強鏄剧ず瀹藉害锛屾湁鏁堟敼鍠勫瓧绗︽嫢鎸ゃ€佽〃鏍肩珫绾垮涓嶉綈绛夐棶棰樸€俓n + +Agent Team 鍜?Sub Agent 鐨勭洰鐨勶紝閮芥槸涓轰簡璁╀富 Agent 鐨勪笂涓嬫枃淇濇寔娓呯埥锛岄檷浣庝笂涓嬫枃鍘嬬缉棰戠巼锛屽噺灏戝叧閿俊鎭涪澶辩殑椋庨櫓銆侫gent Team 杩樿兘骞惰璋冨害浜掍笉渚濊禆鐨勫瓙浠诲姟锛岀缉鐭搷搴旀椂闂淬€俓n浣員UI 杩欒竟鏈変釜闂锛氫负浜嗚绛夊緟涓嶉偅涔堢劍铏戯紝鐣岄潰涓婁細鏄剧ず褰撳墠姝e湪鍋氫粈涔堬紝浣嗚緭鍑哄唴瀹逛竴澶氾紝鐣岄潰灏变贡浜嗭紝杩欎釜杩橀渶瑕佸湪璋冩暣涓嬨€俓n + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=ZjQ4NzYzZDdjZmQ2MjlkN2MxMGRjYWMwYTRlZWJmNmFfMzNiMjI4Y2MyNmY5YTIwNWZhYTI3ZjMwNjM5OWE1MWNfSUQ6NzYzOTAyNzU5NzMzNDIxOTcyNV8xNzc5MTc2MTI1OjE3NzkxNzk3MjVfVjM) + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=N2NlZjVjNmFiNWE4OTY1YzYzN2VkNDdhYWYxMTM4NzFfODJmMTI1YTdiODQzZGE5YWNlYmY2YTg4MWVkN2MxNWRfSUQ6NzYzOTAyNzY4ODg1MzgzNDk0OV8xNzc5MTc2MTI1OjE3NzkxNzk3MjVfVjM) + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=YzRkYmFlNTAxMDRjZTFmNWFmNzIwODJiOGIwZjMzMzRfMzZjZTBlZWUxY2Q0MTA1Zjk4OTZkYzFhNmMwMTg4ZDZfSUQ6NzYzOTAyOTM1NDYyNzU2NjgxMl8xNzc5MTc2MTI1OjE3NzkxNzk3MjVfVjM) diff --git a/docs/doc_25_Document_25.md b/docs/doc_25_Document_25.md new file mode 100644 index 0000000..68beca2 --- /dev/null +++ b/docs/doc_25_Document_25.md @@ -0,0 +1,34 @@ +# 2026.5.11-鏃ユ姤-寮犲鎸痋n +## 宸ヤ綔鍐呭姒傝堪 + +1銆佺户缁暣鐞嗕箣鍓嶅涔犳暣鐞嗙殑Agent + +--- + +## 涓€銆佷笂涓嬫枃绠$悊 + +鎴戣涓篈gent 宸ョ▼閲屾渶闅剧殑涓€鍧楁槸涓婁笅鏂囩鐞嗭細瑕佸悓鏃跺吋椤剧郴缁?Prompt銆佹妧鑳戒笌宸ュ叿璇存槑銆佸杞璇濄€佸伐鍏?鎶€鑳借繑鍥炲唴瀹癸紝浠ュ強浼氬悗鐨勬妧鑳芥彁鐐间笌鐢熸垚锛堝 GEPA 绛夛級銆備换涓€鐜妭杩囬暱锛岄兘浼氭尋鍘嬬湡姝g敤浜庢帹鐞嗙殑鏈夋晥绐楀彛銆俓n +**缃戦〉绫诲伐鍏蜂笌浣撶Н** + +鍏稿瀷渚嬪瓙鏄?*涓€娆¤姹傛媺鍥炴暣椤?HTML**锛氬叾涓?JS銆丆SS銆佹爣绛句笌姝f枃寰堝鏄撴妸涓皬妯″瀷鐨勪笂涓嬫枃鍗犳弧銆傚綋鍓嶅仛娉曟槸灏介噺涓嶈蛋瑁?curl 鎷夊叏椤碉紝鏀逛负閫氳繃 Jina銆丼erper 绛?API 鍋氭娊鍙栨垨妫€绱㈠瀷缁撴灉锛屾帶鍒惰繘鍏ュ璇濈殑鏂囨湰閲忥紱鍚庣画濡傛湁鏇村悎閫傜殑鏈湴瑁佸壀/鎶藉彇鏂规锛屽啀璇勪及鏇挎崲鎴栬ˉ鍏呫€俓n +**宸ュ叿鎵ц缁撴灉涓庢ā鍨嬭涓?* +鎶€鑳?宸ュ叿鎵ц鍦ㄦ鏋朵晶浼氬尯鍒?`ok` / `error` / `missing`銆傚け璐ユ椂浠嶄細鎶婂搴?`tool` 娑堟伅锛堝惈閿欒璇存槑锛屽鏈敞鍐屾垨寮傚父淇℃伅锛夊啓鍏ヤ細璇濓紝渚夸簬妯″瀷鍦ㄥ悗缁疆娆′腑鎰忚瘑鍒拌皟鐢ㄥけ璐ワ紝浠庤€岃嚜鏌ュ弬鏁般€佸伐鍏峰悕鏄惁瀛樺湪銆佹槸鍚﹂渶鎹㈡妧鑳芥垨閲嶈瘯锛涗笉浼氬湪澶辫触鐬棿闈欓粯涓㈠純锛屾槸鍚︿粠涓婁笅鏂囦腑绉婚櫎鍙敱绛栫暐鎴栨ā鍨嬩娇鐢?**閫氳繃绉婚櫎宸ュ叿璁板綍鐨勬柟寮?*澶勭悊銆俓n +**涓婁笅鏂囧帇缂╋紙涓汉鏈熸湜褰㈡€侊級** + +褰撲笂涓嬫枃鎺ヨ繎棰勮涓婇檺鏃讹紝甯屾湜閲囩敤绋冲畾缁撴瀯锛氱郴缁熶晶 Prompts 濮嬬粓鍥哄畾鍦ㄥ簭鍒楁渶鍓嶏紱涓棿瀵瑰巻鍙查噷鐩稿涓嶉噸瑕佺殑瀵硅瘽涓庡伐鍏烽暱鏂囧仛涓€娆℃憳瑕佸帇缂╋紝鍓旈櫎鍣0銆佷繚鐣欎换鍔′富绾夸笌鍏抽敭缁撹锛涙憳瑕佷箣鍚庡啀缁х画鎸夋甯告柟寮忚拷鍔犳柊鐨勭敤鎴锋秷鎭笌妯″瀷鍥炲锛屼繚璇?*鏍稿績鎸囦护 + 鍘嬬缉鍚庣殑鍘嗗彶瑕佺偣 + 鏈€鏂拌繘灞?*鍙銆佸彲缁亰銆俓n +## **浜屻€丼killCurator锛堟妧鑳界瓥灞?鎶€鑳戒粨搴撴暣鐞嗭級** + +Curator 涓轰細璇濈粨鏉熷悗鑷姩璺戠殑涓€浣嶆妧鑳芥暣鐞嗗憳锛氫笓闂ㄧ湅杩欎竴杞璇濋噷鍋氫簡浠€涔堛€佹ā鍨嬬瓟浜嗕粈涔堬紝鍐嶇粨鍚堝綋鍓嶉」鐩噷宸叉湁鐨勬妧鑳藉垪琛紝鍒ゆ柇瑕佷笉瑕佸姩鎵嬫敼涓€鏀规妧鑳芥潗鏂欍€俓n +**鑳藉共浠€涔堬細** + +- **浼樺寲鎶€鑳介噷鐨勬弿杩扮被鍐呭**锛堜緥濡傝鏄庢枃瀛椼€佹€庝箞璋冪敤鏇村悎閫傘€佺ず渚嬫槸鍚﹀ソ鎳傦級锛岃鍚庨潰鐨勫璇濇洿瀹规槗閫夊鎶€鑳姐€佸皯韪╁潙銆俓n- 蹇呰鏃惰ˉ涓€鐐?*璇存槑鎬у皬鏂囨。**锛堜粛闄愪簬鎶€鑳界洰褰曞唴銆佸亸璇存槑涓庣淮鎶わ紝涓嶄唬鏇夸富鍔╂墜鍘诲畬鎴愮敤鎴蜂换鍔★級銆俓n +涓嶨EPA鐨勫尯鍒玕n +- GEPA锛?*杩欒疆瀵硅瘽鍊间笉鍊煎緱鍔ㄤ唬鐮佹垨鏁翠唤鎶€鑳?*锛涘彧鏈夊畠璁や负璇ュ垱寤?鍗囩骇鏃舵墠浼氳窇锛屼笉浼氫笓闂ㄤ负浜?*鍙敼涓ゅ彞璇存槑**鑰岃交閲忚窇涓€瓒熴€俓n- Curator锛?*涓嶅姩鎴栧皯鍔ㄩ€昏緫锛屼笓闂ㄧ粰鎶€鑳借ˉ璇存槑涔︺€佹鼎鎻忚堪**锛屾洿杞汇€佹洿涓撱€俓n +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=MWEwNWIzOTU5NDFhZmI3NDQyNGM5M2MxMThlZjA3NTFfMTBmMTZjNDhhZDYwODUyMzAxNjNkMmRmOGIyMzQ1NzVfSUQ6NzYzODY3OTE3MjgxNDExMzc1M18xNzc5MTc2MTI2OjE3NzkxNzk3MjZfVjM) + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=ZGJmMDhkNGNmNmYxOWE2MzliYzkwZDFhNzFmZmY0MjJfMDgyMDIyM2E2MjM4NGM0MmI3YTAwMDQzYmI4MGI5N2RfSUQ6NzYzODY3OTcxNjAxODQ3NDIwMl8xNzc5MTc2MTI2OjE3NzkxNzk3MjZfVjM) + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=MDk4NzIxMzg5ZTcyZjFkODdjMTczODE4MTYyODJkYTZfN2NlMGNmYjhkNzY5ODE0MWFmNzk4ZTM3YWMyODQxNjZfSUQ6NzYzODY3OTU2NjkxOTI5MDA3MV8xNzc5MTc2MTI2OjE3NzkxNzk3MjZfVjM) + + +**涓婁笅鏂囪川閲忔槸 Agent 鑳藉惁绋冲畾鍙戞尌浣滅敤鐨勫叧閿洜绱犮€?*Agent 鏈€澶х殑浠峰€煎湪浜?*甯姪鐢ㄦ埛鎶婁换鍔$浉鍏崇殑淇℃伅缁撴瀯鍖栥€佽繛璐寲銆?*鎶婄洰鏍囥€佺害鏉熴€佷腑闂寸粨璁轰笌澶栭儴缁撴灉缁勭粐鎴愬彲鎸佺画鎺ㄨ繘鐨勪笂涓嬫枃锛屼粠鑰岄檷浣庡弽澶嶈鏄庝笌淇℃伅閬楁紡甯︽潵鐨勬垚鏈€俓n diff --git a/docs/doc_26_Document_26.md b/docs/doc_26_Document_26.md new file mode 100644 index 0000000..ca3ca8c --- /dev/null +++ b/docs/doc_26_Document_26.md @@ -0,0 +1,57 @@ +# 2026.5.8-鏃ユ姤-寮犲鎸痋n +## 宸ヤ綔鍐呭姒傝堪 + +1銆佸涔燣oRA杩涜妯″瀷寰皟 + +--- + + +浠婂ぉ鐪嬪埌Google涓?*Gemma 4鎺ㄥ嚭澶?Token 棰勬祴 (Multi-Token Prediction, MTP) 鑽夌鍣?*锛岃兘灏嗘帹鐞咷emma 4閫熷害鎻愬崌涓ゅ埌涓夊€嶃€傝胺姝屽凡缁忔湁浜咷emini杩欐牱鐨勫ぇ妯″瀷锛屼负浠€涔堣繕瑕佷负Gemma 4涓嬭繖涔堝ぇ鍔熷か銆傛垜鐨勬兂娉曟槸灏忔ā鍨嬬殑鏍稿績浠峰€兼鍦ㄤ簬鈥?*鍙繁搴﹀畾鍒?*鈥濄€侴emma杩欑被寮€婧愬熀搴э紝鐪熸鐨勪綔鐢ㄦ槸琚紑鍙戣€呮嬁鍘讳簩娆¤捀棣忔垨寰皟锛屾墦纾ㄦ垚閫傞厤鑷韩鍨傜洿涓氬姟鐨勪笓灞炴ā鍨嬶紝鑰孧TP杩欑被鍔犻€熸妧鏈垯璁╀笟鍔¤惤鍦版椂鍝嶅簲鏇村揩銆佹垚鏈洿浣庘€斺€斾粠Gemini娴撶缉鍒癎emma锛屽啀浠嶨emma钂搁鍑虹粏鍒嗗満鏅殑涓撳銆俓n + +## **涓€銆丩oRA鎶€鏈?* + +LoRA 鏄竴绉嶈交閲忕骇鐨勫ぇ妯″瀷寰皟鎶€鏈紝鏍稿績鎬濇兂鏄湪鍘熷棰勮缁冩潈閲嶆梺杈归檮鍔犱綆绉╃煩闃碉紝浠呰缁冭繖浜涘皬鍙傛暟锛岃€屼笉鍔ㄥ師濮嬫ā鍨嬨€俓n +**锛堜竴锛夊伐浣滃師鐞?* + +- 妯″瀷鍏ㄩ噺寰皟鏃讹紝闇€瑕佹洿鏂板叏閮ㄦ潈閲嶇煩闃?$W$锛屾樉瀛樺拰璁$畻寮€閿€鏋佸ぇ銆俓n- LoRA 鐨勬妸鎴忥細鏉冮噸鏇存柊閲?$螖W$鐢ㄤ袱涓皬鐭╅樀 $B$ 鍜?$A$ 鐨勪箻绉潵杩戜技锛屽嵆 $螖W=BA$锛屽叾涓?A,B*A*,*B* 閮芥槸浣庣З鐭╅樀锛屽弬鏁伴噺杩滃皬浜庡師濮?$W$銆俓n- 鍓嶅悜璁$畻鍙樹负锛?h=Wx+BAx$銆傝缁冩椂鍐荤粨 $W$锛屽彧鏇存柊 $A$ 鍜?$B$銆俓n +**锛堜簩锛夎兘骞蹭粈涔?* + +- **鏋佷綆鎴愭湰寰皟澶фā鍨?*锛?鍦ㄥ崟涓秷璐圭骇鏄惧崱涓婂氨鑳藉井璋?7B銆?3B 鐢氳嚦鏇村ぇ鐨勬ā鍨嬨€俓n- **澶氫换鍔″揩閫熷垏鎹?*锛?涓嶅悓浠诲姟鍙渶淇濆瓨鍜屽姞杞戒笉鍚岀殑 LoRA 鏉冮噸鏂囦欢锛堥€氬父鍑?MB 鍒板嚑鍗?MB锛夛紝鏃犻渶涓烘瘡涓换鍔″瓨涓€浠藉畬鏁存ā鍨嬨€俓n- **棰嗗煙閫傞厤涓庝釜鎬у寲**锛?鐢ㄥ皯閲忛鍩熸暟鎹嵆鍙閫氱敤澶фā鍨嬪彉鎴愨€滆涓氫笓瀹垛€濓紝濡傚尰鐤楅棶绛斻€佹硶寰嬫枃涔︺€佹父鎴?NPC 浜烘牸鍖栫瓑銆俓n- **淇濇姢鍘熸ā鍨嬭兘鍔?*锛?涓嶇牬鍧忓熀搴фā鍨嬬殑閫氱敤鐭ヨ瘑锛屽彲闅忔椂鎻掓嫈锛屽嚑涔庢棤鐏鹃毦鎬ч仐蹇橀闄┿€俓n- **缁撳悎鐭ヨ瘑钂搁**锛?鍙笌鈥滃ぇ妯″瀷鏁欏皬妯″瀷鈥濇祦绋嬪ぉ鐒堕厤鍚堬紝璁╁皬妯″瀷鍦ㄧ壒瀹氫换鍔′笂浠ユ瀬灏忎唬浠风户鎵垮ぇ妯″瀷鑳藉姏銆俓n +## **浜屻€佺粨鍚堢煡璇嗚捀棣忕殑濂藉** + +1. **涓€涓€氱敤澶фā鍨嬶紝澶嶅埗鍑哄涓笓鐢ㄥ皬妯″瀷** + +鐢ㄥぇ妯″瀷閽堝涓嶅悓浠诲姟鍒嗗埆鐢熸垚璁粌鏁版嵁锛屾暀鍑哄鏈嶅皬妯″瀷銆佹憳瑕佸皬妯″瀷銆佺紪绋嬪皬妯″瀷绛夈€傛瘡涓皬妯″瀷鍙仛涓€浠朵簨锛屾晥鏋滄洿绋炽€佹洿濂借皟浼樸€俓n +1. **闄嶄綆瀵归珮绔‖浠剁殑渚濊禆** + +涓嶆槸鎵€鏈夊満鏅兘閫傚悎閰嶅鏄傝吹鐨勬湇鍔″櫒闆嗙兢锛屽皬妯″瀷璁╃畻鍔涙湁闄愮殑鐜涔熻兘鐢ㄤ笂濂界敤鐨?AI銆俓n +1. **鎴愭湰澶у箙闄嶄綆** + +澶фā鍨嬭窇涓€娆¢渶瑕佺殑鏄惧崱鍜屾椂闂磋繙澶氫簬灏忔ā鍨嬨€傚悓鏍风殑鏈嶅姟锛屾崲灏忔ā鍨嬭兘璁╂湇鍔″櫒寮€閿€闄嶅埌鍑犲崄鍒嗕箣涓€銆傚鏋滄嬁API鏉ヨ皟鐢紝澶фā鍨嬭皟鐢ㄦ垚鏈瘮杈冮珮锛屼笉閫傚悎浣庢敹鍏ョ殑鍦烘櫙锛岃€屽皬妯″瀷鍙互鐩存帴璺戝湪鏈湴鏈嶅姟鍣ㄥ氨琛岋紝瀵规湇鍔″櫒鐨勮姹備篃娌℃湁閭d箞楂樸€俓n +1. **鍝嶅簲閫熷害鎴愬€嶆彁鍗?* + +澶фā鍨嬬敓鎴愪竴娈佃瘽鍙兘瑕佸ソ鍑犵锛屽皬妯″瀷寰€寰€涓嶅埌涓€绉掋€傜敤鎴风瓑寰呮椂闂寸煭锛屽悓鏃惰兘鏈嶅姟鏇村鐨勭敤鎴枫€俓n +## 涓夈€佸涔犲疄璺礬n +涓轰簡寰皟鐨勯€熷害锛岄€夌敤鐨勬ā鍨嬪熀搴ф槸`gemma-3-1b`锛岄€氳繃LM Studio杩涜璋冪敤 + +**锛堜竴锛夋簮鐮佹暣鐞嗕笌绉嶅瓙鏋勫缓** + +- 閫氳繃寮€婧愰」鐩娊鍙栨簮鐮佺墖娈?鏂囦欢锛岀敓鎴愯缁冪瀛愭彁绀鸿瘝锛岀洰鏍囨槸璁╁悗缁暀瀛﹀唴瀹圭揣璐翠笟鍔′唬鐮併€俓n +**锛堜簩锛夐€氳繃 MiniMax 杩涜鏁欏鏁版嵁鐢熸垚** + +- 璋冪敤 MiniMax API锛屽姣忎釜婧愮爜鏍锋湰鐢熸垚楂樿川閲忚瑙d笌鏀硅繘寤鸿銆俓n- 灏嗐€屾簮鐮? MiniMax 璁茶В銆嶆嫾鍚堟垚鐩戠潱鏁版嵁锛屽舰鎴?`train.jsonl`銆俓n- 瀵逛綆璐ㄩ噺鏍锋湰鍋氭竻娲楋紝鎻愬崌璁粌鏁版嵁瀵嗗害鍜屽噯纭€с€俓n +**锛堜笁锛塙nsloth LoRA 寰皟璁粌** + +- 浣跨敤 `unsloth/gemma-3-1b-it-unsloth-bnb-4bit` 杩涜寰皟銆俓n- 鏈疆鍦ㄥ凡鏈夋潈閲嶅熀纭€涓婄画璁紙`gemma-lora-v1 -> gemma-lora-v2`锛夛紝鎻愰珮瀵归」鐩唬鐮侀鏍间笌瑙i噴鑳藉姏鐨勯€傞厤銆俓n +**锛堝洓锛夎缁冪粨鏋滀笌妯″瀷浜х墿** + +- 鎴愬姛浜у嚭鏂扮殑 LoRA 閫傞厤鍣ㄦ潈閲嶏紙`gemma-lora-v2`锛夈€俓n- 璁粌 loss 鏀舵暃姝e父锛岃繘鍏ラ儴缃茶浆鎹㈤樁娈点€俓n +**锛堜簲锛夐儴缃查摼璺噯澶囷紙鏈湴LM Studio璋冪敤锛?* + +- 鎸夋祦绋嬫墽琛岋細LoRA 鍚堝苟鍏ㄩ噺妯″瀷 -> 杞?GGUF(F16) -> 閲忓寲(Q4_K_M) -> 瀵煎叆 LM Studio銆俓n +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=OGJmYjljMzcyOWIwNmRkNDcyOTBmYjg4NTJmYjE0MGZfNjhjMWRiNTllNTkzMmQzNjQxMTFhYmYzZTI2ZTNjZmFfSUQ6NzYzNzUyNDA1MjQzMzI5MjIxNl8xNzc5MTc2MTI3OjE3NzkxNzk3MjdfVjM) + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=M2ZmNTc4N2FlNjY3YTZhNWQwZDM4YjcyMjM1Y2Q1NjlfZTY4NTYzOTJmMDRmZDFkNTdkNWQyZGQ1MDczN2ZmMzFfSUQ6NzYzNzUzMTg0NzIwNzA0NjM1OV8xNzc5MTc2MTI3OjE3NzkxNzk3MjdfVjM) + + +璇曚笅鏉ユ劅瑙夛紝1B妯″瀷鐨勫簳瀛愮‘瀹炲亸钖勶紝鐢熸垚鍐呭杩樻槸瀹规槗鈥滆儭瑷€涔辫鈥濄€備笉杩囩粡杩囦竴娈垫椂闂村涔犲悗锛屽湪杈撳嚭鏍煎紡鍜岄鏍间笂鏄庢樉鍚戝畠鐨勨€滃笀鍌呪€滿inimax闈犳嫝浜嗐€俓n diff --git a/docs/doc_27_Document_27.md b/docs/doc_27_Document_27.md new file mode 100644 index 0000000..ca08c86 --- /dev/null +++ b/docs/doc_27_Document_27.md @@ -0,0 +1,48 @@ +# 2026.5.13-鏃ユ姤-寮犲鎸痋n +## 宸ヤ綔鍐呭姒傝堪 + +1銆佺户缁暣鐞嗕箣鍓嶅涔犳暣鐞嗙殑Agent + +--- + +## 涓€銆佹彁绀鸿瘝鍒嗗眰 + +灏嗗師鏈贩鏉傚湪涓€璧风殑鎻愮ず绯荤粺鎷嗚В涓轰笁灞傜嫭绔嬭惤鐩樸€佷簰涓嶈€﹀悎鐨勮鍒欓泦锛歕n +- **宸ョ▼灞傦紙浠撳簱绾э級**锛氭壙杞藉綋鍓嶄唬鐮佷粨搴撴墍闇€鐨勫崗浣滅害瀹氾紝鍖呮嫭椤圭洰瑙勮寖銆佸伐鍏疯皟鐢ㄥ崗璁€侀鍩熸湳璇拰娴佺▼绾︽潫锛岃窡闅忎粨搴撹繘琛岀増鏈帶鍒躲€俓n- **鐢ㄦ埛灞傦紙涓汉璺ㄩ」鐩級**锛氭矇娣€涓汉绋冲畾鐨勪娇鐢ㄥ亸濂斤紝渚嬪瑙掕壊璁惧畾銆佽緭鍑洪鏍笺€佸父鐢ㄥ伐浣滄祦鍜屽簳绾胯姹傦紝涓€浠界淮鎶わ紝鍦ㄦ墍鏈変粨搴撲腑澶嶇敤銆俓n- **鍏ㄥ眬灞傦紙浜у搧閫氱敤濂戠害锛?*锛氬畾涔変骇鍝佸叏鍩熷繀椤婚伒瀹堢殑鍩虹嚎瑙勫垯锛屾瘮濡傚畨鍏ㄧ孩绾裤€佹晱鎰熸暟鎹鐞嗙瓥鐣ャ€佽緭鍑烘牸寮忓己绾︽潫锛屼綔涓烘渶浣庨檺搴︾殑鍏滃簳淇濋殰銆俓n +姣忔浼氳瘽鍚姩鍓嶏紝涓嶅啀浠庢贩鏉傜殑鏂囨湰涓复鏃舵嫾鍑戞寚浠わ紝鑰屾槸鎸夐瀹氱殑浼樺厛绾у拰缁撴瀯锛屾妸璁板繂銆佺敾鍍忋€佺敤鎴风墖娈点€侀」鐩墖娈电粍瑁呮垚涓€鏉¤竟鐣屾竻鏅般€佹棤鍐茬獊鐨勪笂涓嬫枃锛屾敞鍏ョ郴缁熸寚浠ゃ€備笁灞傚悇鑷嫢鏈夌嫭绔嬬殑瀛樺偍浣嶇疆鍜屽姞杞藉紑鍏筹紝鍙樻洿浜掍笉褰卞搷銆俓n +### **锛堜竴锛変负浠€涔堣杩欐牱鍋?* + +鍘熸潵鐨勫仛娉曟槸灏嗘墍鏈夎鍒欏叏閮ㄥ啓鍏ュ悓涓€涓厤缃枃浠躲€傝繖浼氱洿鎺ュ紩鍙戝洓涓棶棰橈細 + +- **椤圭洰鍒囨崲鎴愭湰楂?*锛氫釜浜哄亸濂戒笌椤圭洰瑙勫垯娣卞害浜ょ粐锛屾洿鎹粨搴撴椂蹇呴』鎵嬪伐鍓ョ锛屽緢瀹规槗娈嬬暀鏃犲叧璁惧畾銆俓n- **鐗堟湰瀹℃煡涓嶅彲琛?*锛氬伐绋嬪彉鏇翠笌涓汉鍋忓ソ娣峰湪涓€璧凤紝杩涜 PR 瀹℃煡鏃舵棤娉曞尯鍒嗕慨鏀规潵婧愶紝涔熼毦浠ュ垽鏂奖鍝嶇殑杈圭晫銆俓n- **涓婁笅鏂囩獥鍙f氮璐?*锛氬ぇ閲忓褰撳墠浠诲姟鏃犵敤鐨勪俊鎭閲嶅鍔犺浇锛屾尋鍗犳ā鍨嬬殑娉ㄦ剰鍔涜祫婧愶紝鍚屾椂澶氭潯鐭涚浘鎸囦护骞跺瓨锛屼細闄嶄綆杈撳嚭鐨勪竴鑷存€у拰鍑嗙‘鐜囥€俓n- **闀挎湡缁存姢鍥伴毦**锛氫换浣曚竴澶勫井璋冮兘闇€瑕佸湪澶ч噺鏂囨湰涓畾浣嶏紝瀹规槗浜х敓鎰忓瑕嗙洊锛屽鑷寸淮鎶や汉鍛樹笉鏁㈣交鏄撴敼鍔ㄣ€俓n +鏍规湰鍘熷洜鍦ㄤ簬缂轰箯鍒嗗眰闅旂锛屼娇寰椾笉鍚岀敓鍛藉懆鏈熴€佷笉鍚岃矗浠讳富浣撶殑瑙勫垯寮鸿绯呭悎锛屽鐢ㄦ€с€佸彲瀹℃煡鎬у拰鍙帶鎬у叏閮ㄥ彈鎹熴€俓n +### **锛堜簩锛夋€濊矾** + +鏍稿績鎬濊矾鏄妸鎻愮ず褰撴垚涓€绉嶉渶瑕佹灦鏋勮璁$殑璧勪骇锛岃€屼笉鏄竴娈甸殢鎰忕矘璐寸殑鏂囨湰銆俓n +棣栧厛锛屼笁灞傚搴斾笁绉嶅畬鍏ㄤ笉鍚岀殑鍙樻洿棰戠巼鍜岃礋璐d富浣撱€傚伐绋嬪眰鐢遍」鐩淮鎶よ€呭湪浠撳簱鍐呯洿鎺ョ鐞嗭紝鍙互璧版爣鍑嗙殑 Code Review 娴佺▼锛涚敤鎴峰眰灞炰簬涓汉閰嶇疆锛屽簲褰撶嫭绔嬩簬椤圭洰瀛樺湪锛屾洿鎹粨搴撴椂鑷姩鎸傝浇锛涘叏灞€灞備唬琛ㄤ骇鍝佸畨鍏ㄥ簳绾匡紝蹇呴』闆嗕腑绠℃帶锛屼笉鑳借灞€閮ㄤ慨鏀硅交鏄撹鐩栥€傝繖绉嶅垏鍒嗗ぉ鐒惰В鍐充簡鏉冮檺绠$悊鍜屽彂甯冩祦绋嬬殑闂銆俓n +鍏舵锛屾瘡娆′細璇濆皢鍒嗘暎鐨勮蹇嗗拰鐢诲儚杩涜鎵撳寘娉ㄥ叆锛屾槸涓轰簡鏋勫缓涓€鏉$ǔ瀹氫笖鍙娴嬬殑涓婁笅鏂囧熀绾裤€傞€氳繃瑙勫畾鏄庣‘鐨勬嫾鎺ラ『搴忓拰瑕嗙洊瑙勫垯锛屽嵆浣挎潵婧愬鏍凤紝鏈€缁堢敓鎴愮殑鎸囦护涔熸槸纭畾鎬х殑锛岄伩鍏嶆ā鍨嬪洜鎸囦护娉㈠姩鑰屼骇鐢熻涓烘紓绉汇€俓n +鏈€鍚庯紝鍒嗗眰鐨勯暱杩滄敹鐩婂湪浜庨檷浣庤鐭ヨ礋鎷呭拰缁存姢鎴愭湰銆傚垵鏈熼渶瑕佹惌寤哄姞杞介€昏緫锛屼絾涓€鏃﹁繍杞捣鏉ワ紝鍚庣画鏂板瑙勫垯銆佽皟鏁村亸濂芥垨杩涜鐏板害娴嬭瘯锛岄兘鍙互鍦ㄥ搴斿眰绾у唴瀹氬悜鎿嶄綔锛屼笉浼氬鍏朵粬灞傞€犳垚杩為攣褰卞搷銆俓n +--- + +## 浜屻€佺敓鎴愭妧鑳界殑浜屾鎻愮偧 + +瀵硅嚜鍔ㄧ敓鎴愮殑鎶€鑳斤紝寤虹珛浜嗕竴濂椾細鑷姩瑙﹀彂鐨勭淮鎶ら摼璺細 + +- **琛ュ厖鏍¢獙涓庡閮ㄥ姞宸?*锛氭瘡涓柊鎶€鑳界敓鎴愬悗锛岃嚜鍔ㄨ繍琛屽悎瑙勬鏌ワ紝琛ュ叏缂哄け鐨勫弬鏁板拰瑙﹀彂鏉′欢锛屽苟鍙牴鎹厤缃皟鐢ㄥ閮ㄨ剼鏈繘琛屽姛鑳介獙璇侊紝纭繚涓嶅彧鏄兘鎵ц锛岃€屼笖鎵ц缁撴灉姝g‘銆俓n- **鍛ㄦ湡鎬х洰褰曟暣鐞嗕笌鍚堝苟鏀剁揣**锛氬畾鏈熸壂鎻忔湰鍦版妧鑳界洰褰曪紝璇嗗埆璇箟楂樺害杩戜技鎴栧姛鑳介噸鍙犵殑鎶€鑳藉寘锛岃繘琛岃嚜鍔ㄥ寲鎴栧崐鑷姩鍖栫殑鍚堝苟涓庡幓閲嶏紝灏嗗叾鎶借薄涓烘洿閫氱敤鐨勫熀纭€鎶€鑳斤紝鎶戝埗鐩綍鏁伴噺鐨勬棤搴忓闀裤€俓n- **鍙鐢ㄥ亸濂界嫭绔嬫彁鐐?*锛氬皢鈥滀唬鐮佸瀷鎶€鑳解€濓紙宸ュ叿璋冪敤銆佽嚜鍔ㄥ寲娴佺▼锛夊拰鈥滆嚜鐒惰瑷€鍋忓ソ鈥濓紙璇皵銆佽鑹层€佽〃杈鹃鏍硷級鍒嗘垚涓ゆ潯鐙珛鐨勭鐞嗙嚎锛屽垎寮€閰嶇疆銆佸垎鍒紨鍖栥€傚亸濂介儴鍒嗕細琚彁鐐兼垚杞婚噺鐨勨€滃彲澶嶇敤鍋忓ソ鐗囨鈥濓紝鍏剁増鏈€佸紑鍏冲拰鍔犺浇绛栫暐涓庢妧鑳藉寘瀹屽叏瑙h€︺€俓n +鏁翠釜娴佺▼鍦ㄤ細璇濈粨鏉熷悗鏍规嵁閰嶇疆鑷姩鎵ц锛屽舰鎴愨€滅敓闀库€旀牎楠屸€旀暣鐞嗏€旀彁鐐尖€濈殑鎸佺画缁存姢闂幆銆俓n +### 锛堜竴锛変负浠€涔堣杩欐牱鍋歕n +鐩存帴浠庡璇濅腑浜х敓鐨勬妧鑳斤紝澶╃劧瀛樺湪涓や釜鏄捐憲缂洪櫡锛歕n +- **鍐椾綑閲嶅涓ラ噸**锛氭ā鍨嬪鏄撳洜涓嶅悓鐨勫璇濊〃杩拌€岀敓鎴愭湰璐ㄧ浉鍚屼絾鍚嶇О銆佺粏鑺傜暐鏈夊樊寮傜殑鎶€鑳斤紙渚嬪鈥滄煡澶╂皵鈥濆拰鈥滆幏鍙栧ぉ姘斺€濓級銆傚鏋滀笉鍔犳敹鏁涳紝鎶€鑳界洰褰曚細鍦ㄧ煭鏈熷唴蹇€熻啫鑳€锛屽厖婊″姛鑳介噸鍙犵殑鍖呫€俓n- **璐ㄩ噺涓嶇ǔ鍥?*锛氳繖浜涙妧鑳藉線寰€缂哄皯瀹屾暣鐨勫弬鏁板畾涔夈€佽竟鐣屾潯浠跺鐞嗗拰娓呮櫚鐨勮Е鍙戣鍒欙紝澶勪簬鍕夊己鍙敤鐘舵€併€傜洿鎺ユ姇鍏ヤ娇鐢ㄤ細骞叉壈妯″瀷鍐崇瓥锛屽鑷磋緭鍑轰笉绋冲畾鎴栭敊璇€俓n +鑻ヤ笉杩涜浜屾澶勭悊锛屾妧鑳藉簱浼氳繀閫熶粠鏈夌敤璧勪骇閫€鍖栦负缁存姢璐熸媴锛屾帓閿欏拰鏁寸悊鐨勬垚鏈皢杩滆秴鍏跺甫鏉ョ殑鏀剁泭銆俓n +### **锛堜簩锛夋€濊矾** + +鎶€鑳借祫浜х殑鎸佺画闆嗘垚鍜屾寔缁暣鐞嗘祦绋嬶紝鎶€鑳介渶瑕佺粡杩囨牎楠屽拰閲嶆瀯鎵嶈兘绋冲畾鍏ュ簱銆俓n +灏嗏€滀唬鐮佸瀷鎶€鑳解€濆拰鈥滆嚜鐒惰瑷€鍋忓ソ鈥濇媶寮€澶勭悊锛屾槸鍩轰簬涓よ€呮紨鍖栬妭濂忓拰娌荤悊鏂瑰紡鐨勬牴鏈樊寮傘€傛妧鑳界被浼间簬鍔熻兘妯″潡锛屼細棰戠箒杩唬銆佸悎骞跺拰鎶借薄锛岄渶瑕佷弗鏍肩殑鐗堟湰鎺у埗鍜屽紑鍏崇鐞嗭紱鑰屽亸濂藉垯鏇存帴杩戠敤鎴烽厤缃紝鍐呭杞婚噺銆佸彉鍖栬緝鎱紝骞朵笖闇€瑕佸湪鎵€鏈夊満鏅腑淇濇寔涓€鑷淬€傚鏋滃己琛屾崋缁戯紝浠讳綍鍋忓ソ鐨勫井灏忚皟鏁达紙姣斿淇敼涓€鍙ユ儻鐢ㄨ锛夐兘浼氳Е鍙戞妧鑳藉寘鐨勯噸鏂板彂甯冨拰娴嬭瘯锛岃繖鏄剧劧涓嶅悎鐞嗐€傝В鑰﹀悗锛屼袱鏉$嚎鍙互鎸夌収鍚勮嚜鐨勯€熷害婕旇繘锛屽亸濂借皟鏁寸敋鑷充笉闇€瑕佽Е鍙婃妧鑳藉寘鐨勭増鏈彿銆俓n +閫夋嫨鍛ㄦ湡鎬ф暣鐞嗚€屼笉鏄疄鏃跺己鍒跺幓閲嶏紝鏄洜涓烘柊鐢熸妧鑳介渶瑕佷竴娈佃瀵熸湡銆傜粡杩囧嚑娆′細璇濈殑瀹為檯璋冪敤鍜岄獙璇侊紝鎵嶈兘鏇村噯纭垽鏂畠鏄惁鐪熺殑涓庡凡鏈夋妧鑳介噸澶嶏紝浠ュ強瀹冪殑绋冲畾杈圭晫鍦ㄥ摢閲屻€傜粰浜堣繖娈电紦鍐茬獥鍙o紝鍙互閬垮厤杩囨棭鍚堝苟瀵艰嚧鏈夌敤鍙樹綋琚鍒犮€俓n +--- + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=YjcxNzk1Yjk1ZjEzMTA5YWVkZTFiOWRiNjA2Y2IwZTBfYmFlZmNkNjdlY2IwYjJlN2YxMjViNDM2YzJkMTg0YThfSUQ6NzYzOTQzNzg0NzYzOTk2ODk3M18xNzc5MTc2MTI4OjE3NzkxNzk3MjhfVjM) + + +缁忚繃杩欐鏃堕棿鐨勫涔犲拰瀹炶返锛屾垜瀵?AI Agent 鐨勬暣浣撹剦缁滄湁浜嗘瘮杈冩竻鏅扮殑鎶婃彙锛屽嚑涓叧閿幆鑺傜殑鎬濊矾涔熷熀鏈疮閫氾細 +- **涓婁笅鏂囧帇缂?*锛氱悊瑙d簡濡備綍鍦ㄦ湁闄愮獥鍙e唴淇濈暀楂樹环鍊间俊鎭紝閫氳繃鍒嗗眰銆佹憳瑕佸拰瑁佸壀绛栫暐锛屾妸璁板繂銆佺敾鍍忋€侀」鐩墖娈甸珮鏁堟墦鍖呮敞鍏ワ紝鑰屼笉鏄畝鍗曟埅鏂垨鍫嗙爩銆俓n- **鎶€鑳芥彁鐐?*锛氭帉鎻′簡浠庡璇濅腑鑷姩鎻愬彇銆佹牎楠屻€佸幓閲嶅拰鏀舵暃鎶€鑳界殑鏂规硶锛岃鎶€鑳藉簱浠庘€滆兘璺戜絾涓嶇ǔ鈥濊繘鍖栧埌绋冲畾鍙鐢紝鎶戝埗鐩綍鑶ㄨ儉銆俓n- **Team Agent 涓?Sub Agent**锛氬帢娓呬簡澶?Agent 鍗忎綔鐨勬嫇鎵戠粨鏋勶紝鏄庣‘浜嗕富 Agent 濡備綍鎷嗗垎浠诲姟銆佽皟搴﹀瓙 Agent锛屼互鍙婂郊姝ら棿鐨勯€氫俊濂戠害鍜屼笂涓嬫枃闅旂鏂瑰紡銆俓n- **鎻愮ず璇嶅垝鍒?*锛氬缓绔嬩簡宸ョ▼灞傘€佺敤鎴峰眰銆佸叏灞€灞傜殑鍒嗗眰娌荤悊鎬濊矾锛屾寜鍙樻洿棰戠巼鍜岃礋璐d富浣撹В鑰︼紝璁╄鍒欏悇鍙稿叾鑱岋紝瑙e喅浜嗘贩鍚堥厤缃笅浜掔浉瑕嗙洊銆侀毦浠ュ鏌ョ殑闂銆俓n杩欏嚑鍧椾覆鑱旇捣鏉ワ紝灏辨瀯鎴愪簡浠庡簳灞傝蹇嗙鐞嗗埌涓婂眰澶氭櫤鑳戒綋鍗忎綔鐨勫畬鏁磋鐭ラ摼鏉°€俓n diff --git a/docs/doc_2_Document_2.md b/docs/doc_2_Document_2.md new file mode 100644 index 0000000..42b8530 --- /dev/null +++ b/docs/doc_2_Document_2.md @@ -0,0 +1,133 @@ +2026骞?鏈?3鏃ュ伐浣滄棩鎶?榛勯潤闆?/title> + +# 涓€銆佸伐浣滃唴瀹规杩癨n +1. 銆婁笁鍥斤細璋嬪畾澶╀笅銆嬨€併€婁笁鍥斤細澶╀笅褰掑績銆嬨€併€婁笁鍥斤細鍐版渤鏃朵唬銆嬩綋楠孿n2. 銆婃垜鐨勮姳鍥笘鐣屻€嬩綋楠孿n3. AI鐮旂┒宸ヤ綔娴佷笌浜у搧璁ょ煡璧勪骇搴撴惌寤烘帹杩沑n + + +# 浜屻€丄I鐮旂┒宸ヤ綔娴佷笌浜у搧璁ょ煡璧勪骇搴撴惌寤烘帹杩沑n +> 鍘熷畾寮€鍙戣鍒掑寘鎷細 +> +> 1. **鍥哄寲 Feishu MCP Source User SOP** +> +> - 姊崇悊 source user 浣跨敤璇存槑 +> - 鍥哄寲 auth / smoke / sync / classify 鏍囧噯鍛戒护 +> - 鏄庣‘甯歌閿欒涓庡鐞嗘柟寮廫n> - 璇存槑 data / dist / token / env 鐩綍澶勭悊瑙勫垯 +> - 浠庡共鍑€ git 鐘舵€佸璺戜竴娆$鍒扮娴佺▼ +> - 灏?SOP 鍐欏叆 README 鎴?workflow 鏂囨。 +> - 琛ュ厖 HTML 鐗堟湰锛屾彁楂樺彲璇绘€n> - 鐢熸垚 share 椤甸潰锛屼究浜庡洟闃熼槄璇籠n> +> 1. **銆婁笁鍥斤細璋嬪畾澶╀笅銆嬭ˉ榻?P0 瀹屾暣闂幆** +> +> - 鍩轰簬涓夎皨宸插悓姝ヨ祫鏂欑敓鎴愯祫浜у€欓€夋竻鍗昞n> - 浜哄伐 review锛岀‘璁ゅ摢浜涘€欓€夊€煎緱娌夋穩 +> - 鐢熸垚 MECH / REPORT / ORG 鍗$墖 +> - 杈撳嚭 HTML 椤甸潰 +> - 涓庛€婃垜鐨勮姳鍥笘鐣屻€嬪舰鎴愬姣旀渚媆n> - 妫€鏌ョ浜屼骇鍝?SOP 鏄惁鐪熸鍙鐢╘n +## 锛堜竴锛変粖鏃ヨ凯浠e唴瀹筡n +**瀹屾垚鈥滃崐鑷姩鐭ヨ瘑璧勪骇鐢熶骇閾捐矾鈥濈殑 P0 鏈湴楠岃瘉锛屾敮鎸佹妸鏃ュ父鐮旂┒璧勬枡杞寲涓虹粨鏋勫寲鐭ヨ瘑璧勪骇锛涗絾姝e紡鍏ュ簱銆佸浜?review銆乼arget 鐭ヨ瘑搴撳啓鍥炲拰鍏ㄨ嚜鍔ㄩ棴鐜粛闇€瑕佺户缁帹杩?* + +杩囧幓澶ч噺鐮旂┒缁撹娌夋穩鍦ㄥ垎鏁g殑椋炰功鏂囨。涓紝闅句互澶嶇敤锛涚幇鍦ㄥ紑濮嬫妸璧勬枡鍚屾銆佸€欓€夎瘑鍒€佹満鍒跺崱鐗囥€丠TML灞曠ず銆佺储寮曞彂鐜拌繖涓€鏁村娴佺▼鍥哄寲涓嬫潵锛?*璁╂垬鐣ョ爺绌堕儴鐨勭爺绌剁粨鏋滈€愭鍙樻垚閮ㄩ棬鍙婄粍缁囧唴閮ㄩ暱鏈熷彲澶嶇敤鐨勭煡璇嗚祫浜?* + +> 瀹為檯涓婏紝鐢变簬Feishu MCP鐩墠璁捐浣跨敤鐨勬槸user_access_token锛堝彲璇诲彇鐢ㄦ埛鏈夋潈闄愮殑鏂囨。锛夛紝鐞嗚涓婂彧瑕佹垜鐨勮处鍙锋湁璁块棶鏉冮檺锛屾墍鏈夌殑浜戞枃妗o紙doc/docx锛夊潎鍙澶勭悊杞寲涓虹煡璇嗚祫浜n + + +### 鍥哄寲 Feishu MCP Source User SOP + +Feishu MCP Source User SOP 宸插畬鎴?P0 鍩虹鍥哄寲锛?*鍏峰鏀拺绗簩浜у搧楠岃瘉鍜屽悗缁煡璇嗚祫浜х敓浜х殑鑳藉姏**锛屼絾姝e紡鐭ヨ瘑搴撳啓鍥炰笌澶氫汉鍗忎綔娴佺▼浠嶅睘浜?v0.4+ 瑙勫垝銆傚熀浜庡墠涓€鏃ュ凡璺戦€氱殑 Feishu MCP Source User 閾捐矾锛屽皢鍏惰繘涓€姝ユ暣鐞嗕负**鍙槄璇?*銆?*鍙鐢?*銆?*鍙氦鎺?*鐨?SOP 鏂囨。锛屽苟鍚屾鐢熸垚浜?HTML / share 椤甸潰銆備富瑕佸畬鎴愬唴瀹瑰寘鎷細 + +- 鍥哄寲 Feishu MCP Source User 鐨勪娇鐢ㄨ竟鐣孿n- 鏄庣‘缁勭粐1 / 缁勭粐2鐨勫叧绯诲拰瀹氫綅 +- 琛ュ厖 source user OAuth銆乻moke銆乻ync銆乧lassify 鐨勬爣鍑嗗懡浠よ鏄嶾n- 鍖哄垎缁堢鍛戒护涓?Claude Code MCP 宸ュ叿璋冪敤 +- 鏄庣‘ data / dist / token / env 绛夌洰褰曞鐞嗚鍒橽n- 琛ュ厖甯歌閿欒涓庡鐞嗘柟寮廫n- 鐢熸垚 Feishu MCP Source User SOP 鐨?HTML 椤甸潰涓?share 鐗堟湰 +- 灏?SOP 閾炬帴涓庡叆鍙e悓姝ュ埌 README / 宸ヤ綔娴佹€昏涓璡n +鐐瑰嚮鏌ョ湅锛歔Feishu MCP Source User SOP 鈥?鎴樼暐鐮旂┒閮╙(https://feishu-mcp-source-user-sop.netlify.app/) + +<grid> +<column width-ratio="0.612697"> +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=OGRjNzk5ZjlmMWViZGZkZTZiYzcyZmQzZDg0MTdiMzNfYzQyZmZlN2ZjNmUzODZjYWY0NmM5MTczNDRjNjk4ZWFfSUQ6NzYzOTQ3ODE2Mzg2MDQ1ODQ2OV8xNzc5MTc2MTExOjE3NzkxNzk3MTFfVjM) +</column> +<column width-ratio="0.387303"> +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=MWRkZWY5NjFlMTcxNTQ4Njc1MDc0N2JjOGFkOWNmYzVfN2QyYjYxNGQzOTQ0NjAxNWNjMzIxMWMyMWZiNzExZTVfSUQ6NzYzOTQ3ODI2NDQ2MDc0MTgxMF8xNzc5MTc2MTExOjE3NzkxNzk3MTFfVjM) +</column> +</grid> + + + +### 銆婁笁鍥斤細璋嬪畾澶╀笅銆婸0 鏈湴闂幆楠岃瘉 + +鎺ㄨ繘銆婁笁鍥斤細璋嬪畾澶╀笅銆嬩綔涓虹浜屼釜浜у搧妗堜緥鐨?P0 楠岃瘉锛岄噸鐐规槸楠岃瘉銆婃垜鐨勮姳鍥笘鐣屻€嬪凡缁忚窇閫氱殑宸ヤ綔娴佹槸鍚﹁兘澶熻縼绉诲埌涓嶅悓鍝佺被浜у搧涓娿€傜洰鍓嶇粨璁烘槸锛?*SOP 鍏峰浜у搧鏃犲叧鎬э紝宸查€氳繃绗簩浜у搧楠岃瘉锛屽綋鍓?SOP 宸茬粡鍏峰璺ㄤ骇鍝佸鐢ㄨ兘鍔?* + +- 閫氳繃 Feishu MCP source user 璺緞杩涜 dry-run 鎼滅储锛屽洿缁曚笁涓叧閿瘝鏌ユ壘鏇村悎閫傜殑涓夎皨鏉愭枡锛歕n + - 涓夎皨 婕旀澶т細 + - 涓夎皨 绠$悊灞傜敓鎬佷綅 + - 涓夊浗锛氳皨瀹氬ぉ涓?闂紟璧涘鑷€夊墽鏈満鍒? +- 缁忚繃 dry-run 鍚庯紝鏈€缁堥€夋嫨浠モ€滄紨姝﹀ぇ浼氣€濅负涓夎皨 P0 鐨勭涓€缁勭煡璇嗚祫浜ч獙璇佸璞°€傚洿缁曚笁璋嬫紨姝﹀ぇ浼氬畬鎴愪簡锛歕n + - 鍩轰簬 3鏈?5鏃?/ 3鏈?6鏃?/ 3鏈?0鏃ョ浉鍏虫棩鎶ユ潗鏂欒繘琛屽唴瀹瑰悓姝n - 璇诲彇 raw_content 杩涜鏈哄埗鍒嗘瀽 + - 鐢熸垚浜哄伐 review 鍚庣殑鍊欓€夎祫浜n - **鐢熸垚涓夌被鐭ヨ瘑鍗$墖**锛? + + - **MECH 鍗★細鏈哄埗妯″瀷鍗?* + + > **杩欎釜鏈哄埗濡備綍鎴愮珛锛?* + > + > 鏍稿績浠峰€煎畾浣嶏細娌夋穩鈥滃彲澶嶇敤鏈哄埗妯″瀷鈥漒n + - **REPORT 鍗★細浜у搧瑙傚療鎶ュ憡鍗?* + + > **杩欎釜鏈哄埗涓轰粈涔堝浜у搧鏈変环鍊硷紵** + > + > 鏍稿績浠峰€煎畾浣嶏細娌夋穩鈥滀骇鍝佸眰鍒ゆ柇鈥漒n + - **ORG 鍗★細缁勭粐鐮旂┒鍗?* + + > **杩欎釜鏈哄埗濡備綍闄嶄綆缁勭粐鍘嬪姏锛屽苟鏋勫缓浣庣粍缁囧帇鍔涘弬涓庡満鏅紵** + > + > 鏍稿績浠峰€煎畾浣嶏細娌夋穩鈥滅粍缁囧弬涓庣粨鏋勫彉鍖栤€漒n - **鍥寸粫涓夎皨婕旀澶т細褰㈡垚鐨勬牳蹇冨垽鏂?*锛歕n + - 婕旀澶т細涓嶆槸鍗曠函鐨勫叕骞崇珵鎶€鐜╂硶锛岃€屾槸涓夎皨鍦ㄧ巼鍦焞ike妗嗘灦涓嬫瀯閫犵殑鈥滃彈鎺у叕骞崇珵鎶€鐜鈥濓紝閫氳繃鍘嬬缉澶ч儴鍒嗗吇鎴愬樊璺濓紝鎶婅儨璐熺劍鐐逛粠闀挎湡鏁板€肩Н绱浆鍚戦厤灏嗙悊瑙c€佹垬娉曠粍鍚堜笌鍗氬紙鍐崇瓥锛屽悓鏃剁敤鐭懆鏈熷懆甯?PVP 琛ヨ冻闀垮懆鏈熻禌瀛?GVG 鐨勫唴瀹圭┖绐椼€傚畠鐨勪环鍊间富瑕佷綋鐜板湪鍑犱釜鏂归潰锛歕n + - **闄嶄綆鏅€氱帺瀹跺拰鏂版墜鐞嗚В閰嶅皢绯荤粺鐨勬垚鏈?* + 婕旀澶т細閫氳繃鍙楁帶璧勬簮姹犮€佹棤绾€佹棤闊暐銆侀殢鏈烘娊鍙栥€佹敮鎻翠綅绛夎璁★紝鎶婄帺瀹舵媺鍒颁竴涓浉瀵瑰叕骞崇殑鐜涓紝璁╃帺瀹惰兘鏇翠綆鎴愭湰鍦扮悊瑙f灏嗗畾浣嶃€佹垬娉曠粍鍚堛€侀樀瀹瑰厠鍒跺拰閰嶅皢鍗氬紙 + - **涓洪珮鐞嗚В浣庝粯璐圭帺瀹舵彁渚涜〃杈剧┖闂?* + 浼犵粺鐜囧湡like涓紝楂樼悊瑙d絾浣庝粯璐圭帺瀹跺線寰€鍦ㄤ富绾胯禌瀛d腑缂哄皯瓒冲琛ㄨ揪绌洪棿銆傛紨姝﹀ぇ浼氬帇缂╁吇鎴愬樊璺濆悗锛岃閰嶅皢鐞嗚В鍜屽崥寮堝垽鏂洿瀹规槗琚湅瑙乗n - **琛ヨ冻璧涘闀垮懆鏈熷唴瀹圭┖绐?* + 鐜囧湡like璧涘鍛ㄦ湡闀匡紝璧涘鏈鏄撳嚭鐜板唴瀹圭┖鐧姐€傛紨姝﹀ぇ浼氶€氳繃鍛ㄥ父鍖栥€佷綆缁勭粐鍘嬪姏銆佸崟浜哄彲鍙備笌鐨勭煭鍛ㄦ湡 PVP锛屼负璧涘澶栨彁渚涚ǔ瀹氬唴瀹硅ˉ浣峔n - **鍏峰娼滃湪鍟嗕笟杞寲浠峰€?* + 婕旀澶т細鍙兘閫氳繃鈥滆瘯鐜╂晥搴斺€濃€滄敮鎻翠綅妯悜鎶藉彇鈥濃€滈煬鐣ユ劅鐭モ€濃€滃鍔卞弽鍝轰富绾库€濈瓑鏂瑰紡浜х敓娼滃湪鍟嗕笟鍖栦环鍊硷紝浣嗙洰鍓嶆病鏈夋娊鍗°€佹祦姘淬€佹椿璺冦€佺暀瀛樼瓑鏁版嵁鏀拺锛屽彧鑳戒綔涓?C 绫绘帹婕旓紝涓嶈兘鍐欐垚浜嬪疄缁撹 + - 杈撳嚭涓夊紶鍗$墖瀵瑰簲鐨?HTML 椤甸潰 + - 鐢熸垚涓夎皨 P0 case 鑱氬悎椤礬n - 鐢熸垚 share 鍖匼n - 灏嗕笁璋?P0 楠岃瘉缁撴灉鍐欏叆宸ヤ綔娴佹€昏锛沑n - 涓庛€婃垜鐨勮姳鍥笘鐣屻€嬫渚嬬殑瀵规瘮锛岄獙璇佸悓涓€濂?P0 SOP 鏄惁鍏峰璺ㄤ骇鍝佸鐢ㄨ兘鍔沑n +鐐瑰嚮鏌ョ湅锛歔銆婁笁鍥斤細璋嬪畾澶╀笅銆嬫紨姝﹀ぇ浼?P0 鐭ヨ瘑璧勪骇妗堜緥](https://sanguomoudingyanwudahuip0case.netlify.app/) + +<grid> +<column width-ratio="0.241077"> +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=MzJkNTFlZTM2MmNhYjQ3MTRmYTUzMzMzZmU2NDE4ZDVfMGYyZDYzNTJhZTllMTA4MTljZTg4YTk1YjIyMjQzMDhfSUQ6NzYzOTQ5NjM1MDkzMjk0NTg2OV8xNzc5MTc2MTExOjE3NzkxNzk3MTFfVjM) +</column> +<column width-ratio="0.241077"> +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=YTRhODA2OWJkNjE5ZmZhMGFlMmE4MmJlNzBiMDMwZGFfNjlmNmY2NGM5YzdlYWY1NGNlMmU0NjZlNDE5MzRmZTRfSUQ6NzYzOTQ5NjUyMjkzNzE1ODg1MV8xNzc5MTc2MTExOjE3NzkxNzk3MTFfVjM) +</column> +<column width-ratio="0.284245"> +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=NmI4NzkwZTA4NTY5OTFlZDg2MTIzY2ZiZGZmNGNhMDJfYmJmM2I4OTk1MDQ3ZmI5NWZmYzdmMWUyMThjYWUwMThfSUQ6NzYzOTQ5NzQxNDc4NDYxNzY5NF8xNzc5MTc2MTExOjE3NzkxNzk3MTFfVjM) +</column> +<column width-ratio="0.233601"> +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=YzNhMjQ2NTE5NTdhYWQwOGQwNzNiYjNmZjQ1YTRlZjVfYWRjMWEwY2U5YmJlNTY5OWU2MzVhZjgzZjZhNGYwYmFfSUQ6NzYzOTQ5NzQ4OTA4Njc5NDk0NV8xNzc5MTc2MTExOjE3NzkxNzk3MTFfVjM) +</column> +</grid> + +<grid> +<column width-ratio="0.680672"> +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=YzRjMmExNzk1MDBiYmE2YWEzYWZhYjE4ZGY1MDRkNGJfYTI4MmVjMTcyODE0MTU4YzU0NDZlNWEzMTRlMzMzN2RfSUQ6NzYzOTQ4NzE0Mjg5ODA3NjYxMl8xNzc5MTc2MTExOjE3NzkxNzk3MTFfVjM) +</column> +<column width-ratio="0.319328"> +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=ZWVjZDNhOWM4MTUyNjE4MjA4MGMzZWI4MjI4YjkxMzVfMjY2YWU2OTU1ZjdjMGRmOWNhZWIwNjYzZDZhYWFjODBfSUQ6NzYzOTQ4NzI0MDE1Mzg3NzY5OF8xNzc5MTc2MTExOjE3NzkxNzk3MTFfVjM) +</column> +</grid> + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=MTg4NGQ0ZmU1NDViYWMyNzEyMDBiMmQ1ZGE4Y2U3NjRfMjIxNGM1ZWFkNmIyMzU0ZjZkZWEzYTQ3MWY5Yjg0ZjNfSUQ6NzYzOTQ3NzE3MTI2OTkzMDE5Nl8xNzc5MTc2MTExOjE3NzkxNzk3MTFfVjM) + + + +### **鎴樼暐鐮旂┒閮?AI 宸ヤ綔娴佸紑鍙戣繘搴︽€昏鏇存柊** + +- 鐐瑰嚮鏌ョ湅锛歔鎴樼暐鐮旂┒閮?AI 鐮旂┒宸ヤ綔娴佹€昏](https://strategyresearchaiworkflowoverview.netlify.app/) + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=Y2M2MjkxYWRkZTI1OTExZDRiOTk4Y2JkNmJlYTE1MzFfNjI0ZTNjZmI4YTMzOGJmNTdiMTBjMTY0NTg0NmE4OGRfSUQ6NzYzOTQ3Njg2MDA5ODc0MzQ4MV8xNzc5MTc2MTExOjE3NzkxNzk3MTFfVjM) + + + + + +## 锛堜簩锛夋槑鏃ヨ鍒抃n +1. 涓夎皨涓夊紶 draft 鍗℃寮忓叆搴?review +2. 鍥哄寲 MECH / REPORT / ORG 鍚屾簮鎷嗗垎瑙勫垯 +3. 涓妯″閲忓悓姝ラ獙璇乗n4. 鍒嗙被鍊欓€変骇鐗╁彲璇诲寲 +5. target 鍐欏洖鐭ヨ瘑搴撶殑瑙﹀彂鏉′欢姊崇悊 diff --git a/docs/doc_3_Document_3.md b/docs/doc_3_Document_3.md new file mode 100644 index 0000000..2108bd5 --- /dev/null +++ b/docs/doc_3_Document_3.md @@ -0,0 +1,186 @@ +<title>2026骞?鏈?5鏃ュ伐浣滄棩鎶?榛勯潤闆?/title> + +# 涓€銆佸伐浣滃唴瀹规杩癨n +1. 鍙傚姞GGS2026鍏ㄧ悆娓告垙宄颁細 + + + +# 浜屻€丟GS2026鍏ㄧ悆娓告垙宄颁細鏀惰幏涓庢€濊€僜n +浠婂ぉ鍙傚姞GGS2026鍏ㄧ悆娓告垙宄颁細锛圓I鐮斿彂&涓彴涓撳満锛夛紝娑电洊浜嗘父鎴忓叕鍙稿湪AI鐖嗗彂鏃朵唬涓嬬殑鎴樼暐閫夋嫨銆佷粠绔嬮」銆佺爺鍙戙€佽繍钀ャ€佹暟鎹垎鏋愯凯浠g瓑鍚勪釜鏂归潰娣卞害搴旂敤AI鐨勫疄璺靛垎浜紝鍚屾椂涔熷弽鏄犲嚭AI鏃朵唬涓嬪缁勭粐鏂囧寲銆佹灦鏋勩€佸伐浣滄祦銆佷汉鎵嶆彁鍑轰簡鏂扮殑瑕佹眰 + +## 锛堜竴锛夋€讳綋鍒ゆ柇锛欰I姝e湪鏀瑰彉娓告垙鍏徃鐨勭粍缁囩珵浜夋柟寮廫n +鏈鍑犲満鍒嗕韩鍏卞悓鎸囧悜涓€涓秼鍔匡細 + +**AI瀵规父鎴忓叕鍙哥殑褰卞搷锛屼笉鍙槸涓汉宸ュ叿鎻愭晥锛岃€屾槸鍦ㄩ噸鏋勬父鎴忓叕鍙哥殑浜у搧瀛靛寲銆佺爺鍙戝崗浣溿€佽繍钀ヨ凯浠c€佹暟鎹喅绛栧拰缁勭粐鐭ヨ瘑娌夋穩鏂瑰紡锛屽ご閮ㄥ拰鑵伴儴娓告垙鍏徃宸茬粡杩涘叆閲嶆瀯缁勭粐鐢熶骇绯荤粺鐨勯樁娈?* + +娓告垙鍏徃鐨勭珵浜夋鍦ㄤ粠鈥滃崟涓」鐩粍鑳藉姏鈥濇墿灞曡嚦锛歕n +- 鏄惁鏈?*楂橀鍒涙剰楠岃瘉鏈哄埗** +- 鏄惁鏈?*AI杈呭姪鐮斿彂宸ヤ綔娴?* +- 鏄惁鏈?*缁熶竴鏁版嵁涓庝笟鍔¤瑷€** +- 鏄惁鏈?*杩愯惀/鏁版嵁/鐮斿彂楂樺害鍗忓悓鑳藉姏** +- 鏄惁鑳?*鎶婇」鐩粡楠屾矇娣€鎴怉I鍙皟鐢ㄨ祫浜?* +- 鏄惁鑳?*璁╃粍缁囨寔缁涔狅紝鑰屼笉鏄瘡娆′粠闆跺紑濮?* + + + +## 锛堜簩锛変拱閲忛┍鍔ㄥ叕鍙告洿瀹规槗鍚冨埌AI鍒涙剰楠岃瘉绾㈠埄 + +鍐板窛缃戠粶鏄竴瀹朵拱閲忓拰鏁版嵁椹卞姩鐗瑰緛寰堝己鐨勬父鎴忓叕鍙革紝鍜屼笁涓冪被浼笺€傚畠浠?*涓嶆槸鍗曠函鐩镐俊鍒涙剰**锛岃€屾槸鏇寸浉淇★細 + +**楂橀娴嬭瘯銆佹暟鎹弽棣堛€佸揩閫熺瓫閫夈€佹斁澶ц耽瀹?* + +鍐板窛缃戠粶鍓€诲湪鍒嗕韩閲屾彁鍒帮細 + +1. 鈥滃ソ娓告垙鈥濈殑瀹氫箟涓嶆槸鎶借薄鐨勨€滆壓鏈〃杈锯€濇垨鈥滅簿鍝佸彊浜嬧€濓紝鑰屾槸闈炲父璐磋繎涔伴噺妯″瀷鈥斺€斿惛閲忋€佸ソ鐜┿€佸悗绔晢涓氬寲鎴愮啛 +2. 鈥滃ソ娓告垙鈥濆繀椤诲惛閲忋€佽兘璁╃帺瀹剁帺涓嬪幓锛屽苟涓旇兘鍦ㄦ父鎴忓唴褰㈡垚娑堣垂 +3. **鐖嗘鏈夋鐜囨€э紝鍦ㄥ悓鏍锋椂闂村拰鎴愭湰涓嬮獙璇佹洿澶氭柟鍚戯紝灏卞彲鑳芥彁楂樺懡涓満浼?* + +浠栦滑浠婂勾寤虹珛浜?*鈥淎I娓告垙瓒呯骇涓綋灏忕粍鈥?*锛屾牳蹇冮€昏緫鏄?*閫氳繃AI闄嶄綆鍒涙剰楠岃瘉鎴愭湰锛岀敤鏇翠綆鎴愭湰銆佹洿楂橀鐜囬獙璇佹洿澶氫骇鍝佹満浼?*銆傝繃鍘讳竴涓兂娉曡鎷夌▼搴忋€佺瓥鍒掋€佺編鏈紝鍙兘瑕?鈥?鍛ㄧ敋鑷虫洿涔咃紝鐜板湪鍙互閫氳繃AI蹇€熺敓鎴怘TML5 Demo锛屽苟褰撳ぉ杩唬澶氫釜鐗堟湰 + + + +AI瀵逛拱閲忓瀷鍏徃褰撳墠纭疄鏇存湁鍒╋紝鍥犱负AI寮哄寲鐨勬槸瀹冧滑鍘熸湰灏辨搮闀跨殑**鈥滄祦閲忊€旂礌鏉愨€旀暟鎹€旈獙璇佲€旀斁澶р€?*绯荤粺銆傝繖涓嶆槸璇碅I璁╁垱鎰忔湰韬洿瀹规槗鎴愬姛锛岃€屾槸AI璁╁け璐ユ洿渚垮疁锛岃绛涢€夋洿蹇紝璁╂綔鍦ㄨ耽瀹舵洿鏃╄鍙戠幇 + +- **AI闄嶄綆鐨勬槸璇曢敊鎴愭湰锛屼笉鏄垚鍔熼毦搴?* +- **AI Demo涓嶇瓑浜庡彲涓婄嚎(鏈夊晢涓氬寲鑳藉姏锛変骇鍝?* +- **楂橀鐢熸垚鍒涙剰浼氬揩閫熷唴鍗?* +- **闀挎湡浼樺娍浠嶇劧鍙栧喅浜庣敤鎴风悊瑙c€佷骇鍝佸垽鏂€佸晢涓氬寲鎵挎帴鍜屾暟鎹棴鐜川閲?* + +<callout emoji="馃"> +**璀︽儠锛?* +**蹇笉鏄晢涓氬彉鐜伴€昏緫锛屾弧瓒崇敤鎴封€滃ソ鐜┾€濈殑闇€姹傛墠鏄牳蹇冦€?*濡傛灉鎵€鏈変拱閲忓叕鍙搁兘鐢ˋI鎻愰珮鍒涙剰楠岃瘉鏁堢巼锛岀煭鏈熶細褰㈡垚鏁堢巼绾㈠埄锛涗絾闀挎湡鏉ョ湅寰堝彲鑳戒細鍙樻垚鏂扮殑鍐涘绔炶禌銆傚埌閭f椂锛屽崟绾€滄洿蹇敓鎴愭洿澶氬垱鎰忊€濅細杩呴€熷け鏁堬紝鐪熸绋€缂虹殑浼氶噸鏂板洖鍒帮細**鍝佺被鍒ゆ柇銆佷骇鍝佹墜鎰熴€侀暱鏈熷唴瀹硅兘鍔涖€佸晢涓氬寲缁撴瀯銆佹暟鎹棴鐜川閲忓拰缁勭粐鍐崇瓥璐ㄩ噺** +浣嗗叾涓緢鍊煎緱鍊熼壌瀛︿範鐨勬槸**鎶婁骇鍝佹帰绱㈡媶鎴愬彲楠岃瘉鍋囪锛屽苟褰㈡垚绋冲畾楠岃瘉鏈哄埗** +> 渚嬪瀵瑰吇鎴愩€佽嫳鍕囦箣鍦般€丼LG绫绘柟鍚戞潵璇达細 +> +> **鐢ˋI鍋氭満鍒舵帹婕斻€佺珵鍝佺粨鏋勬媶瑙c€佺敓鎬侀闄╂ā鎷熴€佺増鏈柟妗堢敓鎴愩€佺帺瀹跺弽棣堝綊鍥狅紱浜烘潵鍒ゆ柇鏍稿績浣撻獙鍜岄暱鏈熺粨鏋?* +</callout> + + + +## 锛堜笁锛夊啺宸濈綉缁?*鈥淎I娓告垙瓒呯骇涓綋灏忕粍锛?*1浜?+ AI Agents鈥濅笌鎴樼暐鐮旂┒閮ㄥ垱鏂扮粍楂樺害鐩镐技 + +鍐板窛缃戠粶鐨凙I娓告垙瓒呯骇涓綋灏忕粍涔熸槸**1浜?+ AI Agents**妯″紡锛屼笉鍐嶆槸浼犵粺绋嬪簭銆佺編鏈€佺瓥鍒掑畬鏁撮厤缃紝涓嶅啀鎸夌▼搴忋€佺編鏈€佺瓥鍒掑垎宸ワ紝姣忎釜浜洪兘鏄€滄父鎴忚璁″笀鈥濄€俓n +涓庢垬鐣ョ爺绌堕儴鍒涙柊缁勭浉浼肩殑鐐逛笉鏄兘鍦ㄧ敤AI鍋氬皬娓告垙锛岃€屾槸**缁勭粐瀹為獙鍋囪鐩镐技**锛歕n +1. **闈炲畬鏁翠紶缁熺爺鍙戦厤缃笅锛屾槸鍚﹀彲浠ョ敱鍏峰浜у搧鍒ゆ柇鍔涚殑浜猴紝鍊熷姪AI Agents瀹屾垚浠庡垱鎰忋€佸師鍨嬨€佽祫婧愩€佷唬鐮併€佹祴璇曞埌杩唬鐨勯棴鐜?* +2. **AI骞舵湭闄嶄綆鍒涢€犲ソ娓告垙鐨勯棬妲涳紝鑰屾槸闄嶄綆鍒涙剰楠岃瘉鎴愭湰锛岀湡姝e喅瀹氭垚璐ョ殑锛屼粛鐒舵槸浜虹殑鍒ゆ柇鍔涗笌瀹$編鑳藉姏** + +**鎵€浠ュ垱鏂扮粍鐨勪笟鍔$洰鏍囧簲璇ユ槸鍊熷姪AI瀹屾垚楂橀鍘熷瀷楠岃瘉锛屽苟閫氳繃璇曠帺銆佷笂绾挎祴璇曪紝鍩轰簬鏁版嵁鍜屽鐩樺喅瀹氭槸鍚︾户缁姇鍏ワ紝杩涜蹇€熻凯浠?鍒涙柊**锛?*浜烘墠鍩瑰吇鐩爣鏄妸姣忎釜绛栧垝璁粌鎴愪竴涓叿澶囦骇鍝佸垽鏂€丄I璋冨害銆佸師鍨嬮獙鏀躲€佽凯浠e鐩樿兘鍔涚殑AI娓告垙璁捐甯?* + + + + + +## 锛堝洓锛堿I瀵规柊浜у搧鍜岃€佷骇鍝佺殑浠峰€间晶閲嶇偣涓嶅悓 + +### 瀵规柊浜у搧锛欰I鐨勬牳蹇冧环鍊兼槸鎻愰珮鎺㈢储鏁堢巼 + +鏂颁骇鍝佹渶澶ч棶棰樻槸鏂瑰悜涓嶇‘瀹氾細 + +- 鐜╂硶鏄惁鎴愮珛 +- 鐢ㄦ埛鏄惁涔拌处 +- 棰樻潗鏄惁鍚搁噺 +- 鍟嗕笟鍖栨槸鍚﹁兘鎵挎帴 +- 鏍稿績浣撻獙鏄惁鏈夐暱鏈熸綔鍔沑n +鍥犳AI瀵规柊浜у搧鐨勪环鍊间富瑕佹槸锛歕n +- 闄嶄綆鍒涙剰楠岃瘉鎴愭湰 +- 鎻愰珮鍘熷瀷楠岃瘉瀵嗗害 +- 鏇村揩鐢熸垚Demo +- 鏇村揩鍋氱礌鏉?棰樻潗娴嬭瘯 +- 鏇村揩娣樻卑閿欒鏂瑰悜 +- 鏇存棭鍙戠幇鍊煎緱缁х画鎶曞叆鐨勬満浼歕n +鍏抽敭璇嶆槸锛歕n +**瀛靛寲銆佹帰绱€佸師鍨嬨€佽瘯閿欍€侀獙璇併€佹鐜囨彁鍗?* + +> 鐩涜叮缇庢湳璐熻矗浜哄垎浜簡AI鍦ㄩ」鐩墠鏈熼獙璇佷腑鐨勫簲鐢細**鍔ㄦ€丏emo蹇€熺敓鎴?* +> +> 鐢ㄨ棰戠敓鎴愬伐鍏峰皢闈欐€佸浘鐗囪浆涓哄姩鎬丏emo锛岀瓥鍒掑彲鏋佷綆鎴愭湰鍒朵綔鎺ヨ繎鐪熷疄杩愯鏁堟灉鐨勬紨绀虹墖娈礬n + + +### 瀵硅€佷骇鍝侊細AI鐨勬牳蹇冧环鍊兼槸鎻愰珮杩愯惀鍜屽唴瀹硅凯浠f晥鐜嘰n +**AI鍦ㄦ父鎴忚涓氭渶鍏堜骇鐢熺ǔ瀹氫环鍊肩殑锛屼笉鍙槸鍙戣杩愯惀鍜屾暟鎹腑鍙帮紝涔熷寘鎷€佷骇鍝侀暱绾垮唴瀹硅凯浠c€?* + +鑰佷骇鍝侀€氬父宸叉湁锛歕n +- 鏄庣‘鐢ㄦ埛缇n- 鎴愮啛鍟嗕笟鍖栫粨鏋刓n- 绋冲畾鐗堟湰鑺傚 +- 鍘嗗彶娲诲姩妯℃澘 +- 鏃㈡湁鏁版嵁璧勪骇 +- 宸茬煡鐢ㄦ埛鐥涚偣 +- 鍙鐢ㄧ編鏈€佹暟鍊笺€佽繍钀ユ鏋禱n +鍥犳AI鍦ㄨ€佷骇鍝侀噷鐨勪环鍊兼洿鐩存帴锛歕n +- 娲诲姩鏂规鍒濈 +- 鑺傛棩娲诲姩鍖呰 +- 鑰佹椿鍔ㄥ鍒诲拰鍙樹綋 +- 杩愯惀鏂囨鍜屽叕鍛奬n- 閰嶇疆琛ㄦ鏌n- 鐜╁鍙嶉褰掑洜 +- 娲诲姩鏁版嵁澶嶇洏 +- 鐢ㄦ埛鍒嗗眰鍙洖 +- 绱犳潗鎵归噺鐢熸垚 +- 寮傚父棰勮 +- 鍑忓皯杩愯惀浜嬫晠 + +鍏抽敭璇嶆槸锛歕n +**闄嶆湰銆佹彁鏁堛€佸鐢ㄣ€佺洃鎺с€佸鐩樸€佸噺灏戜簨鏁呫€佸彂鐜扮粨鏋勬€ч棶棰樸€佹彁楂樺唴瀹圭殑璐ㄩ噺銆佸尮閰嶅害鍙婁緵缁欐晥鐜?* + +<sheet sheet-id="DYNVsz" token="BSwIsrb1ihG5yAtJLr6cegp0nPh"></sheet> + + + +## 锛堜簲锛堿I鐮斿彂鎻愭晥褰撳墠澶勪簬鈥滃眬閮ㄦ晥鐜囨彁鍗団€旀祦绋嬮噸鏋勬帰绱⑩€濈殑闃舵 + +4399銆佺洓瓒g瓑鍏徃鐨勫垎浜簡AI宸ヤ綔娴佸娓告垙寮€鍙戞彁鏁堢殑瀹炶返锛歕n +- 绛栧垝鏂囨。Markdown鍖朶n- 閰嶇疆琛ㄨ緟鍔‐n- AI璇勫绛栧垝鏂囨。 +- PSD/PUI鑷姩鍖朶n- 瑙勮寖椹卞姩寮€鍙慭n- 灏忓瀷鍔熻兘寮€鍙慭n- 鍘熷瀷楠岃瘉 + +AI宸ヤ綔娴佸灞€閮ㄦ晥鐜囩殑鎻愬崌鏋佷负鏄庢樉锛岀湡姝i渶瑕佺獊鐮寸殑鏄?*涓撶敤宸ヤ綔娴佽兘鍔?*锛屽叏娴佺▼鍚屾牱闈复妯″瀷鑳藉姏涓嶈冻鍙婁笂涓嬫枃闄愬埗闂 + + + +## 锛堝叚锛夎繍钀ヤ腑鍙板拰鏁版嵁涓彴鐨勬敹鐩婃洿鐩磋 + +鐩歌緝鐮斿彂鎻愭晥锛屼笁涓冨拰宸ㄤ汉鐨勫垎浜綋鐜板嚭锛歕n +**AI鍦ㄨ繍钀ャ€佸彂琛屻€佹暟鎹垎鏋愩€佺敤鎴疯Е杈俱€佹椿鍔ㄥ鐩樸€佸紓甯哥洃鎺т笂鐨勪环鍊兼洿瀹规槗楠岃瘉** + +涓変竷鐨勮繍钀ヤ腑鍙伴€昏緫鏄細 + +- 缁熶竴娴侀噺鎺ュ叆 +- 瀹氫箟鐩爣鐢ㄦ埛 +- 缁勫悎杩愯惀绛栫暐 +- 缁勪欢鍖栨墽琛孿n- A/B娴嬭瘯 +- 鏁堟灉鍒嗘瀽 +- 鎸佺画杩唬 + +杩欑被鍦烘櫙闂幆鐭紝鎸囨爣鏄庣‘锛岃兘澶熷揩閫熻瀵燂細 + +- 瑙﹁揪鏁堢巼鏄惁鎻愬崌 +- 閰嶇疆鏃堕棿鏄惁鍑忓皯 +- 杩愯惀浜嬫晠鏄惁涓嬮檷 +- 鐢ㄦ埛鏄惁琚纭Е杈綷n- 鎴愭湰鏄惁涓嬮檷 +- 鍥炴祦鐜囥€佽浆鍖栫巼銆佺暀瀛樻槸鍚︽敼鍠刓n +宸ㄤ汉缃戠粶鐨勬暟鎹腑鍙板垯浣撶幇鍑哄彟涓€绉嶄环鍊硷細 + +**AI鍜屾暟鎹笉鏄浛浠d骇鍝佸垽鏂紝鑰屾槸闄嶄綆閿欒鍒ゆ柇銆侀敊璇厤缃€侀敊璇凯浠g殑姒傜巼** + +灏ゅ叾瀵?*鑰佷骇鍝?*銆?*鎴愮啛椤圭洰**銆?*闀挎湡杩愯惀椤圭洰**鏉ヨ锛孉I + 鏁版嵁涓彴鑳借娲诲姩澶嶇洏銆佺増鏈綊鍥犮€佺帺瀹跺弽棣堝垎鏋愩€佸紓甯告娴嬫洿蹇繘鍏ヤ笟鍔″喅绛栭摼璺痋n +鍐板窛寮鸿皟**AI鎻愰珮楠岃瘉棰戠巼**锛屽法浜哄己璋?*鏁版嵁杩涘叆宸ヤ綔娴佸悗鎵嶈兘闄嶄綆鏂瑰悜鍒ゆ柇鍜岃凯浠f垚鏈?*銆備袱鑰呯粨鍚堝悗锛屽畬鏁撮摼璺簲璇ユ槸锛歕n +**AI鍙戠幇鏈轰細 鈫?AI杈呭姪鐢熸垚鍘熷瀷 鈫?浜哄垽鏂牳蹇冧綋楠?鈫?鏁版嵁楠岃瘉鐢ㄦ埛鍙嶉 鈫?AI杈呭姪澶嶇洏 鈫?浜哄喅瀹氭槸鍚︾户缁姇鍏?* + + + +## 锛堜竷锛堿I鍙嬪ソ鍨嬬粍缁囦笌AI鍙嬪ソ鍨嬫灦鏋勪細鎴愪负鏂拌兘鍔沑n +涓変竷/B绔欏拰4399鐨勫垎浜兘鍦ㄥ己璋冿細 + +**鏈潵濂界殑缁勭粐鍜屽伐绋嬩綋绯伙紝涓嶄粎瑕佷汉鍙悊瑙o紝杩樿AI鍙悊瑙c€佸彲璋冪敤銆佸彲楠岃瘉** + +1. 缁熶竴涓氬姟瀵硅薄瀹氫箟 +2. 寤虹珛缁熶竴鎸囨爣鍙e緞 +3. 鎶婇儴闂ㄨ瑷€缈昏瘧鎴愬叡鍚屼笟鍔¤瑷€ +4. 鍏堥€夐珮棰戝満鏅窇灏忛棴鐜痋n5. 寤虹珛鑳藉姏璧勪骇搴揬n +> 鎶婄粍缁囩煡璇嗗彉鎴怉I鍙銆佸彲璋冪敤銆佸彲楠岃瘉銆佸彲澶嶇敤鐨勮祫浜э紝鍖呮嫭锛氱粺涓€鏈銆佹竻鏅板懡鍚嶃€佹帴鍙e绾︺€佸厓鏁版嵁澹版槑銆佺粨鏋勫寲鏂囨。銆佽鑼冨寲鐩綍銆佺粺涓€鍩嬬偣銆佹潈闄愯竟鐣屻€佸彲杩芥函鏉ユ簮銆佹祴璇曞拰楠屾敹鏈哄埗銆乵emory/鐭ヨ瘑搴撴矇娣€ + + + +<callout emoji="馃"> +**灏忕粨锛?* +澶撮儴鍜岃叞閮ㄦ父鎴忓叕鍙稿凡缁忚繘鍏?*閲嶆瀯缁勭粐鐢熶骇绯荤粺**鐨勯樁娈点€傛父鎴忓叕鍙搁棿鐨勭珵浜夋鍦ㄤ粠**椤圭洰缁勮兘鍔涙墿灞曡嚦AI鍖栫殑楠岃瘉绯荤粺銆佺爺鍙戠郴缁熴€佽繍钀ョ郴缁熷拰缁勭粐瀛︿範绯荤粺鑳藉姏** +褰撳墠AI鐨勭‘瀹氭€т环鍊间綋鐜帮細 +1. **杩愯惀涓庢暟鎹紙鏈夊椤圭洰鐨勪腑澶у瀷鍏徃涓€鑸瓨鍦ㄤ腑鍙帮級**鎻愬崌鐢ㄦ埛瑙﹁揪銆佹椿鍔ㄩ厤缃€佹暟鎹鐩樸€佷簨鏁呴闃插拰杩愯惀鍐崇瓥鏁堢巼 +2. **鑰佷骇鍝侀暱绾垮唴瀹硅凯浠?*鏂瑰悜銆佹鏋躲€佺敤鎴峰拰鍟嗕笟鍖栨ā鍨嬬浉瀵圭‘瀹氾紝AI鍙互鐩存帴闄嶄綆鐗堟湰鐢熶骇銆佹椿鍔ㄨ璁°€佺礌鏉愬埗浣溿€侀厤缃鏌ャ€佸弽棣堝綊鍥犲拰澶嶇洏鐨勬垚鏈紝璁╃幇鏈変骇鍝佺敤**鏇翠綆鎴愭湰**銆?*鏇村皯浜嬫晠**銆?*鏇村揩鑺傚**銆?*鏇村噯鍒ゆ柇**缁存寔闀跨嚎鐢熷懡鍔沑n3. **鏂颁骇鍝佸鍖栦笌鐮斿彂鎻愭晥**鎴樼暐浠峰€奸珮锛屼絾甯傚満楠岃瘉閾捐矾闀匡紝涓嶇‘瀹氭€ч珮 +</callout> diff --git a/docs/doc_4_Document_4.md b/docs/doc_4_Document_4.md new file mode 100644 index 0000000..2561c9f --- /dev/null +++ b/docs/doc_4_Document_4.md @@ -0,0 +1,152 @@ +<title>2026骞?鏈?鏃ュ伐浣滄棩鎶?榛勯潤闆?/title> + +# 涓€銆佸伐浣滃唴瀹规杩癨n +1. 銆婁笁鍥斤細璋嬪畾澶╀笅銆嬨€併€婁笁鍥斤細澶╀笅褰掑績銆嬨€併€婁笁鍥斤細鍐版渤鏃朵唬銆嬩綋楠孿n2. 銆婃垜鐨勮姳鍥笘鐣屻€嬩綋楠孿n3. AI鐮旂┒宸ヤ綔娴佷笌浜у搧璁ょ煡璧勪骇搴撴惌寤烘帹杩沑n + + +# 浜屻€丄I鐮旂┒宸ヤ綔娴佷笌浜у搧璁ょ煡璧勪骇搴撴惌寤烘帹杩沑n +## 锛堜竴锛夊綋鍓嶇増鏈唴瀹筡n +褰撳墠鐗堟湰宸茬粡鍏峰鍑犵被鍩虹鑳藉姏锛歕n +1. **鏈湴 Claude Code 鐮旂┒鐢熶骇灞傚凡褰㈡垚鍩烘湰缁撴瀯** + +- 鏈湴宸ヤ綔鍖哄凡缁忓叿澶?workflows銆乼emplates銆乸rompts銆乲nowledge銆乨ata銆乺eports銆乤rchive 绛夌洰褰曠粨鏋勶紝骞堕€氳繃 Git 绠$悊鐗堟湰 +- P0 宸ヤ綔娴佸簳搴т腑宸茬粡鍖呭惈淇℃伅鏀堕泦銆佷簨瀹炴牳楠屻€佺珵鍝佸垎鏋愩€佹満鍒舵媶瑙c€佺ぞ鍖哄弽棣堝垎鏋愩€佷骇鍝佸弽鍝恒€佺煡璇嗗崱鐗囩敓鎴愮瓑鍩虹 SOP + +1. **鐭ヨ瘑鍗$墖浣撶郴宸蹭粠鏈哄埗鍗$墖鎵╁睍鍒板绫诲瀷鍗$墖** + +- 褰撳墠宸茬粡褰㈡垚鏈哄埗鍗$墖銆丄I 鏈轰細鍗$墖銆丱RG 缁勭粐鏂规硶璁哄崱鐗囩瓑澶氱被鐭ヨ瘑璧勪骇 + +1. **鍘嗗彶鎶ュ憡鏈湴闀滃儚娴佺▼宸茶窇閫?* + +- 椋炰功鍘嗗彶璧勬枡宸茬粡鍙互閫氳繃鈥滀汉宸ュ鍒?瀵煎嚭 鈫?鏈湴 Markdown 闀滃儚 鈫?Claude Code 鍒嗘瀽鈥濈殑鏂瑰紡杩涘叆鏈湴鐮旂┒鐢熶骇娴佺▼ + +1. **HTML 灞曠ず涓庡垎浜摼璺凡鍒濇鍙敤** + +- 闄ゅ崟涓満鍒跺崱鐗囧彲鐢熸垚 HTML 杩涜灞曠ず涓庡垎浜锛岃繕鍙粺涓€绔欑偣鍏ュ彛锛屽皢鎬昏椤靛拰澶氫釜鐩稿叧鏈哄埗鍗$墖鏁村悎鍦ㄤ竴璧凤紝骞跺彲閫氳繃 Netlify Drop 绛夐潤鎬佹墭绠℃柟寮忕敓鎴愬彲鍒嗕韩閾炬帴 + +> 鐐瑰嚮鏌ョ湅锛歔鎴樼暐鐮旂┒閮?AI 鐮旂┒宸ヤ綔娴佹€昏](https://capable-lily-6fb2e0.netlify.app/) +> +> <grid> +> <column width-ratio="0.097574"> +> ![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=ZjVhMGI1ZWQ4MTdkMDY5MmUzYjg4ODhhNTliYWRlZDRfZTgyODM2NTlhNmQxM2M2MzQwYmRhMThiNWZiODEzYWFfSUQ6NzYzNzk5MDY3OTI2NzgyMjc5Ml8xNzc5MTc2MTEyOjE3NzkxNzk3MTJfVjM) +> </column> +> <column width-ratio="0.153917"> +> ![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=M2VkNzNmMDgzMmJmZGM3Mjg5NjBiODIzN2NhMjU4YmJfNGUwNDBlNjEzYWEzY2RlYTBjYmNlZWVkNTVhMTAyNDNfSUQ6NzYzNzk5MDgwMTQzNTI2NjI0OV8xNzc5MTc2MTEyOjE3NzkxNzk3MTJfVjM) +> </column> +> <column width-ratio="0.164808"> +> ![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=NDE1NmI0ZmM2NTgyZjM4N2RmYTA3NjJkZjZiM2NiMWVfM2QyOGJmYjkyNTlkMDY0MzNkMzZjNWNjN2JjOTZiYjZfSUQ6NzYzNzk5MDg5Mzk0MDY3MzQ4NF8xNzc5MTc2MTEyOjE3NzkxNzk3MTJfVjM) +> </column> +> <column width-ratio="0.154259"> +> ![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=MGVhNzRjMGY3ZjdhZmMyMTRlZjk2MmE1OTFkYWQ3ODZfMWY2NjBkNzUwYzNlMmNjYTQwNWIwYmQ2ZWFkMzY4ZjVfSUQ6NzYzNzk5MDk2NTA1NTE3OTk5MF8xNzc5MTc2MTEyOjE3NzkxNzk3MTJfVjM) +> </column> +> <column width-ratio="0.119191"> +> ![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=NzRhZTgxODczNzg2ZGM5YWY0ZGNkMDhlZjgxNWU3NWRfYzYzMWExNjNiYTE2MDE0MjY0OTE0ODBhZjIyOWYxZDBfSUQ6NzYzNzk5MTA2MDIyMzgyMjc3OF8xNzc5MTc2MTEyOjE3NzkxNzk3MTJfVjM) +> </column> +> <column width-ratio="0.131544"> +> ![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=YjVlNDgxZjNjMzhiNDIxNTFhMDc1ZjFmNmQ1NjYzYjRfZGM0NWU5MDcyMzg2M2YwMTY3ZWJmNTBhOGEzZmEzN2JfSUQ6NzYzNzk5MTE3MDc5ODI5MjE2Ml8xNzc5MTc2MTEyOjE3NzkxNzk3MTJfVjM) +> </column> +> <column width-ratio="0.178708"> +> ![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=OTAwMTk3YjdkZDdmZDc4NTFmNzQyNjA5NGMzOTBhNTdfYjhiNmM0Y2ZhNDAzOTUyZWQ5OTVkYzAyNDI2OGRmMWJfSUQ6NzYzNzk5MTM5NDI5MTgyOTk2N18xNzc5MTc2MTEyOjE3NzkxNzk3MTJfVjM) +> </column> +> </grid> + + + +## 锛堜簩锛変富瑕佽凯浠e唴瀹筡n +**AI鐮旂┒宸ヤ綔娴佸凡缁忎粠鈥滃崟鐐规満鍒舵媶瑙f祴璇曗€濇帹杩涘埌鈥滃浠藉巻鍙叉姤鍛婃壒澶勭悊涓庡彲瑙嗗寲鍒嗕韩娴佺▼鈥?*锛屽綋鍓嶈兘鍔涘彉鍖栦富瑕佷綋鐜板湪锛歕n +1. **浠庡崟绡囨満鍒舵媶瑙o紝鍗囩骇涓哄浠藉巻鍙叉姤鍛婂鐞?* + +姝ゅ墠涓昏楠岃瘉鐨勬槸鍗曚釜鏈哄埗妗堜緥鑳藉惁鎷嗚В鎴愭姤鍛婂拰鏈哄埗鍗$墖銆傛湰杞垯楠岃瘉浜嗗浠藉巻鍙叉姤鍛婅兘鍚﹂€氳繃 index.md 绠$悊杈撳叆锛屽啀缁熶竴鐢熸垚璧勪骇娓呭崟鍜屽崱鐗囧寲寤鸿 + +1. **浠?Markdown 鍗$墖锛屽崌绾т负 Markdown + HTML 灞曠ず** + +Markdown 浠嶇劧浣滀负鐭ヨ瘑婧愬拰闀挎湡娌夋穩鏍煎紡锛孒TML 鍒欎綔涓哄睍绀哄眰鍜屽垎浜眰銆傝繖涓垎宸ユ瘮杈冩竻鏅帮細鐭ヨ瘑娌夋穩涓嶄緷璧?HTML锛屼絾瀵瑰鍒嗕韩鍜屽唴閮ㄥ揩閫熼槄璇诲彲浠ラ€氳繃 HTML 椤甸潰鎻愬崌鏁堢巼 + +1. **浠庢墜鍔ㄩ浂鏁f搷浣滐紝寮€濮嬪浐鍖栦负 SOP** + +銆婃垜鐨勮姳鍥笘鐣屻€嬭繖涓€杞凡缁忓舰鎴愯緝瀹屾暣鐨勫彲澶嶇敤閾捐矾锛屽悗缁彲浠ョ敤绗簩涓」鐩户缁獙璇佽 SOP 鏄惁绋冲畾 + +--- + +- 鏈疆浠ャ€婃垜鐨勮姳鍥笘鐣屻€嬩负娴嬭瘯瀵硅薄锛屽畬鎴愪簡**浠庡巻鍙叉姤鍛婂埌鏈哄埗璧勪骇鐨勫畬鏁村鐞嗘祦绋?* + + - **椋炰功鍘嗗彶鎶ュ憡鏈湴闀滃儚** + + - index.md 澶氭枃浠剁储寮昞n - 璧勪骇娓呭崟涓庡崱鐗囧寲寤鸿 + - 浜哄伐纭鐢熸垚鍝簺鍗$墖 + - 鏈哄埗鍗$墖 + - HTML 鍗曞崱椤礬n - HTML 鎬昏椤礬n - HTML 绱㈠紩绔欑偣 + - 鍙儴缃插垎浜寘 +- 鏈疆鍏卞鐞嗕袱浠藉巻鍙叉姤鍛婏紝鍦ㄤ汉宸ョ‘璁ゅ悗鐢熸垚涓ゅ紶鏈哄埗鍗$墖锛?*褰撳墠宸ヤ綔娴佸凡缁忓彲浠ュ鐞嗗浠藉巻鍙叉潗鏂欙紝骞朵粠涓彁鐐煎彲澶嶇敤鏈哄埗璧勪骇** + + - **MECH-20260510-002锛氶潪绱浠诲姟涓庢柊鎵嬭涓烘暀鑲叉満鍒?* + - **MECH-20260510-003锛欸VE 鍨嬪叕浼氱珵璧涗笌缁勭粐璐$尞鏈哄埗** + + > 鐐瑰嚮鏌ョ湅锛歕n > + > [MECH-20260510-002 路 闈炵疮璁′换鍔′笌鏂版墜琛屼负鏁欒偛 路 銆婃垜鐨勮姳鍥笘鐣屻€媇(https://sprightly-centaur-e87985.netlify.app/) + > + > [MECH-20260510-003 路 GVE 鍨嬪叕浼氱珵璧涗笌缁勭粐璐$尞 路 銆婃垜鐨勮姳鍥笘鐣屻€媇(https://genuine-mandazi-46a32e.netlify.app/) +- 瀹屾垚 HTML 灞曠ず涓庣粺涓€绱㈠紩绔欑偣锛屽湪鏈哄埗鍗$墖鐢熸垚鍚庯紝杩涗竴姝ョ敓鎴愪簡锛氱粺涓€绱㈠紩绔欑偣瑙e喅浜嗘瘡涓?HTML 閮芥槸鐙珛閾炬帴鐨勯棶棰樸€傜幇鍦ㄥ彲浠ラ€氳繃涓€涓叆鍙i摼鎺ヨ繘鍏ユ€昏椤靛拰涓ゅ紶鏈哄埗鍗$墖锛屾洿鏂逛究**蹇€熼槄璇?*鍜?*杩涗竴姝ュ睍寮€鐩稿叧鏈哄埗闃呰** + + - 涓ゅ紶鏈哄埗鍗曞崱 HTML + - 涓€寮犳満鍒剁爺绌舵€昏 HTML + - 涓€涓粺涓€绱㈠紩绔欑偣 `share/my_garden_world_mechanic_research_site/` + + > 鐐瑰嚮鏌ョ湅锛歔銆婃垜鐨勮姳鍥笘鐣屻€嬫満鍒剁爺绌剁储寮昡(https://fantastic-melomakarona-e70b19.netlify.app/) + > + > ![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=ZDBhZGEzZjJmNjU0ZDVjY2MxZGM3YjA5ZTgyY2ZiNzBfMzdiMzMzZmRiMWI0NGY0NTljMmExZjJlMTcxODBmZmVfSUQ6NzYzNzk4MTgxOTI3NDUyOTk5M18xNzc5MTc2MTEyOjE3NzkxNzk3MTJfVjM) +- 娌夋穩鍘嗗彶鎶ュ憡杞?HTML 绔欑偣 SOP璇?SOP 鍚庣画鍙鐢ㄤ簬鏃ユ姤銆佷笓椤圭爺绌躲€佷細璁邯瑕併€佺珵鍝佽祫鏂欏拰椤圭洰澶嶇洏璧勬枡澶勭悊銆傛祦绋嬫牳蹇冩槸锛歕n + - **鍘嗗彶鎶ュ憡鏈湴闀滃儚** + + - index.md + - 璧勪骇娓呭崟 + - 鍗$墖鍖栧缓璁甛n - 浜哄伐纭 + - 鐭ヨ瘑鍗$墖 + - HTML 鍗曞崱椤礬n - HTML 鎬昏椤礬n - HTML 绱㈠紩绔欑偣 + - Git 鎻愪氦 + + + +## 锛堜笁锛夊綋鍓嶉棶棰樹笌椋庨櫓 + +1. **椋炰功涓?Claude Code 浠嶆湭鑷姩杩炴帴** + +鍘嗗彶鎶ュ憡浠嶉渶瑕佷汉宸ヤ粠椋炰功澶嶅埗鎴栧鍑轰负 Markdown锛孋laude Code 涓嶈兘鐩存帴璇诲彇椋炰功鐭ヨ瘑搴撳唴瀹广€傞涔?API / MCP 鎺ュ叆璺緞鍙互鍚庣画璇勪及锛屼絾褰撳墠浠嶄互鏈湴闀滃儚涓轰富 + +1. **鍘嗗彶鎶ュ憡浜哄伐鏁寸悊鎴愭湰杈冮珮** + +鏈疆鍙鐞嗕簡涓や唤銆婃垜鐨勮姳鍥笘鐣屻€嬫姤鍛婏紝灏卞凡缁忔秹鍙婃牸寮忔暣鐞嗐€乮ndex.md銆佷簨瀹炰慨姝c€丠TML 鐢熸垚銆佸垎浜寘鏁寸悊绛夊涓楠ゃ€傚鏋滃悗缁壒閲忓鐞嗗ぇ閲忔棩鎶ュ拰涓撻」鎶ュ憡锛屼汉宸ラ暅鍍忔垚鏈細閫愭鏄剧幇 + +1. **HTML 鍏綉鍒嗕韩瀛樺湪淇℃伅瀹夊叏椋庨櫓** + +Netlify Drop 绛夐潤鎬佹墭绠℃柟寮忓彲浠ヨВ鍐虫墜鏈虹閾炬帴鎵撳紑闂锛屼絾鐢熸垚鐨勬槸鍏綉鍙闂摼鎺ャ€傚悗缁秹鍙婂唴閮ㄩ」鐩€佹湭鍏紑鍒ゆ柇銆侀」鐩棶棰樿瘖鏂椂锛岄渶瑕佹槑纭劚鏁忚鍒欏拰鍒嗕韩杈圭晫 + +1. **Git remote 灏氭湭閰嶇疆** + +褰撳墠浠撳簱浠嶇劧娌℃湁杩滅▼ remote锛屾墍鏈夋彁浜ら兘鍦ㄦ湰鍦帮紝瀛樺湪鍗曠偣涓㈠け椋庨櫓銆傝繖涓棶棰橀渶瑕佸敖蹇鐞哱n + + +## 锛堝洓锛夊悗缁鍒抃n +1. **琛ュ叏銆婃垜鐨勮姳鍥笘鐣屻€嬪墿浣欓珮浠峰€煎崱鐗?* + +鏍规嵁璧勪骇娓呭崟锛岀户缁ˉ鍏呬釜浜鸿祫浜ц蒋缁戝畾鏈哄埗銆佺ぞ浜ゆ搴﹁В閿佽璁°€併€婃垜鐨勮姳鍥笘鐣屻€嬬珵鍝佹。妗堢瓑鍗$墖锛屼絾闇€瑕佸厛鍒ゆ柇璇佹嵁寮哄害鍜屽鐢ㄤ环鍊硷紝閬垮厤浣庝环鍊煎崱鐗囪啫鑳€ + +1. **閫夋嫨绗簩涓」鐩獙璇?SOP 澶嶇敤鎬?* + +浼樺厛閫夋嫨銆婁笁鍥斤細璋嬪畾澶╀笅銆嬬浉鍏虫姤鍛婄户缁窇鈥滃巻鍙叉姤鍛?鈫?璧勪骇娓呭崟 鈫?鍗$墖 鈫?HTML 绔欑偣鈥濈殑瀹屾暣娴佺▼ + +1. **閰嶇疆 Git remote** + +褰撳墠鏈湴宸ヤ綔鍖哄凡缁忕Н绱緝澶氶噸瑕佹枃浠跺拰 commit锛岄渶瑕佸敖蹇缓绔?GitHub / GitLab 绉佹湁浠撳簱锛屽苟 push 鍒拌繙绋嬶紝閬垮厤鏈湴鍗曠偣椋庨櫓 + +1. **缁х画浼樺寲 HTML 妯℃澘** + +褰撳墠 HTML 宸茬粡鍙敤锛屼絾浠嶅亸鐮旂┒鎶ュ憡褰㈡€併€傚悗缁彲浠ョ户缁紭鍖栨€昏椤靛拰鍗曞崱椤电殑淇℃伅灞傜骇锛屼娇鍏舵洿閫傚悎鎵嬫満绔揩閫熼槄璇汇€佸唴閮ㄤ娇鐢ㄣ€佸垎浜強鏌ヨ + +1. **璇勪及椋炰功 API / MCP 鎺ュ叆蹇呰鎬у強浼樺厛绾?* + +褰撳墠浜哄伐闀滃儚宸茬粡鑳借窇閫氭牳蹇冮摼璺紝鐭湡涓嶅繀鎬ョ潃鎺ラ涔?API銆備絾鍚庣画瑕佹壒閲忓鐞嗗ぇ閲忓巻鍙叉棩鎶ュ拰涓撻」鎶ュ憡锛岄涔﹁嚜鍔ㄨ鍙栬兘鍔涗細鎴愪负鏁堢巼鐡堕锛屽彲浠ヤ綔涓哄悗缁妧鏈獙璇佹柟鍚慭n + + +<callout emoji="馃"> +**灏忕粨**锛歕n瀹屾垚銆婃垜鐨勮姳鍥笘鐣屻€嬪巻鍙叉姤鍛婂鐞嗘祦绋嬬殑瀹屾暣楠岃瘉銆備互涓や唤鍘嗗彶鎶ュ憡涓烘祴璇曟牱鏈紝瀹屾垚浜嗘湰鍦?Markdown 闀滃儚銆乮ndex.md 澶氭枃浠剁储寮曘€佽祫浜ф竻鍗曚笌鍗$墖鍖栧缓璁€佷汉宸ョ‘璁ゅ崱鐗囥€佹満鍒跺崱鐗囩敓鎴愩€丠TML 鍗曞崱椤点€丠TML 鎬昏椤靛拰缁熶竴绱㈠紩绔欑偣鐨勫畬鏁撮摼璺痋n鐩告瘮5鏈?鏃ョ増鏈紝褰撳墠宸ヤ綔娴佸凡缁忎粠鈥滃崟鐐规満鍒舵媶瑙e拰鏈哄埗鍗$墖娴嬭瘯鈥濓紝鎺ㄨ繘鍒扳€滃巻鍙叉姤鍛婃壒澶勭悊 + 鐭ヨ瘑鍗$墖娌夋穩 + HTML 鍙鍖栧垎浜€濈殑闃舵锛歕n**Markdown 浣滀负鐭ヨ瘑婧愶紝knowledge 浣滀负闀挎湡璁ょ煡璧勪骇搴擄紝HTML 浣滀负灞曠ず灞傦紝share 浣滀负瀵瑰鍒嗕韩鍖?*锛岃繖鍑犱釜灞傛鐨勫垎宸ュ凡缁忓垵姝ユ竻鏅癨n褰撳墠宸ヤ綔娴佸凡缁忓叿澶囪繘涓€姝ュ鐢ㄧ殑鍩虹銆傚悗缁細缁х画楠岃瘉 SOP 绋冲畾鎬э紝鍚屾椂閰嶇疆 Git remote锛岄檷浣庢湰鍦板崟鐐归闄╋紝骞惰繘涓€姝ヤ紭鍖?HTML 妯℃澘涓庡垎浜鍒橽n</callout> diff --git a/docs/doc_7_Document_7.md b/docs/doc_7_Document_7.md new file mode 100644 index 0000000..e19c6ed --- /dev/null +++ b/docs/doc_7_Document_7.md @@ -0,0 +1,162 @@ +<title>2026骞?鏈?4鏃ュ伐浣滄棩鎶?榛勯潤闆?/title> + +# 涓€銆佸伐浣滃唴瀹规杩癨n +1. 銆婁笁鍥斤細璋嬪畾澶╀笅銆嬨€併€婁笁鍥斤細澶╀笅褰掑績銆嬨€併€婁笁鍥斤細鍐版渤鏃朵唬銆嬨€併€婃垜鐨勮姳鍥笘鐣屻€嬩綋楠孿n2. 闈㈣瘯 +3. 鐮旂┒缁凙I鐮旂┒宸ヤ綔娴佷笌浜у搧璁ょ煡璧勪骇搴撴惌寤烘帹杩沑n4. 鍒涙柊缁勫叏鏍?AI 寮€鍙戞柟鍚戞€濊€冨強宸ヤ綔娴佹惌寤篭n + + +# 浜屻€佺爺绌剁粍AI鐮旂┒宸ヤ綔娴佷笌浜у搧璁ょ煡璧勪骇搴撴惌寤烘帹杩沑n +> 鍘熷畾寮€鍙戣鍒掑寘鎷細 +> +> 1. 涓夎皨涓夊紶 draft 鍗℃寮忓叆搴?review锛堝凡瀹屾垚锛塡n> 2. 鍥哄寲 MECH / REPORT / ORG 鍚屾簮鎷嗗垎瑙勫垯锛堟湭寮€濮嬶級 +> 3. 涓妯″閲忓悓姝ラ獙璇侊紙鏈紑濮嬶級 +> 4. 鍒嗙被鍊欓€変骇鐗╁彲璇诲寲锛堟湭寮€濮嬶級 +> 5. target 鍐欏洖鐭ヨ瘑搴撶殑瑙﹀彂鏉′欢姊崇悊锛堟湭寮€濮嬶級 + +## 锛堜竴锛変粖鏃ヨ凯浠e唴瀹筡n +### 瀹屾垚銆婁笁鍥斤細璋嬪畾澶╀笅銆嬫紨姝﹀ぇ浼氫笁寮犵煡璇嗗崱姝e紡鍏ュ簱 + +- 瀵逛笁寮犲崱杩涜浜嗘寮忓叆搴撳墠 review锛屽苟瀹屾垚姝e紡鍏ュ簱鐘舵€佸垏鎹n- 鍦?review 涓夊紶鍗$殑杩囩▼涓紝杩涗竴姝ユ槑纭簡鍚屼竴鐮旂┒璧勬枡鎷嗗垎涓哄绫荤煡璇嗗崱鏃剁殑杈圭晫锛歕n + - **MECH 鍗?*锛氬洖绛斺€滄満鍒跺浣曟垚绔嬧€漒n + - 閲嶇偣娌夋穩瑙勫垯缁撴瀯銆佹満鍒舵ā鍨嬨€佽璁¢€昏緫鍜屽彲杩佺Щ鏈哄埗 + - **REPORT 鍗?*锛氬洖绛斺€滄満鍒朵负浠€涔堝浜у搧鏈変环鍊尖€漒n + - 閲嶇偣娌夋穩浜у搧瑙傚療銆佺敤鎴蜂环鍊笺€佷骇鍝佷环鍊煎拰鍟嗕笟鍖栧緟楠岃瘉鏂瑰悜 + - **ORG 鍗?*锛氬洖绛斺€滄満鍒跺浣曞奖鍝嶇帺瀹剁粍缁囦笌鍙備笌缁撴瀯鈥漒n + - 閲嶇偣娌夋穩缁勭粐鍘嬪姏銆佸弬涓庨棬妲涖€佸崗浣滄柟寮忓拰缁勭粐鐢熸€佸奖鍝峔n + > 杩欐涓夎皨婕旀澶т細妗堜緥鏄涓€娆″畬鏁磋窇閫氣€滃悓涓€鐮旂┒瀵硅薄鎷嗗垎涓?MECH / REPORT / ORG 涓夌被鐭ヨ瘑璧勪骇鈥濈殑楠岃瘉妗堜緥銆傝繃绋嬩腑鏆撮湶鍑轰竴涓叧閿棶棰橈細**涓嶅悓鍗$墖涔嬮棿澶╃劧浼氬瓨鍦ㄤ氦鍙夛紝濡傛灉娌℃湁娓呮櫚鐨勬媶鍒嗚鍒欙紝寰堝鏄撳彉鎴愰噸澶嶆€荤粨**銆傚洜姝よˉ鍏呬簡宸ヤ綔娴佽鍒欙紝鏄庣‘涓夌被鍗$墖涓嶆槸骞跺垪澶嶈堪锛岃€屾槸**浠庝笉鍚岀煡璇嗚祫浜ц瑙掓媶鍒嗗悓涓€鏈哄埗瀵硅薄** + > + > 鍚庣画浼氱户缁墿澶ц祫鏂欒妯★紝鍗曠瘒鏉愭枡閲屼細鍚屾椂鍖呭惈锛歕n > + > - 鏈哄埗瑙勫垯 + > - 浜у搧鍒ゆ柇 + > - 鐢ㄦ埛鍙嶉 + > - 缁勭粐鐢熸€乗n > - 鍟嗕笟鍖栨帹婕擻n > - 绔炲搧瀵规瘮 + > - 鍚庣画琛屽姩寤鸿 + > + > 濡傛灉涓嶆媶鍒嗭紝灏变細鍙樻垚涓€绡囪秺鏉ヨ秺闀跨殑缁煎悎鎶ュ憡锛屽悗缁緢闅惧鐢ㄣ€侻ECH / REPORT / ORG 鐨勪环鍊煎湪浜庢妸鐮旂┒鍐呭鎷嗘垚鏇寸ǔ瀹氱殑鐭ヨ瘑鍗曞厓锛歕n > + > - 鏈哄埗 + > - 浜у搧瑙傚療 + > - 缁勭粐鐢熸€佸綊 + > - 鍟嗕笟鍖栨帹婕斾繚鐣欒瘉鎹竟鐣孿n > - C 绫绘帹婕斿垽鏂潪瀹㈣浜嬪疄 + + + +- 鐐瑰嚮鏌ョ湅璇︽儏锛歕n + - [銆婁笁鍥斤細璋嬪畾澶╀笅銆嬫紨姝﹀ぇ浼?P0 鐭ヨ瘑璧勪骇妗堜緥](https://sanguomoudingyanwudahuip0case.netlify.app/) + - [鎴樼暐鐮旂┒閮?AI 鐮旂┒宸ヤ綔娴佹€昏](https://strategyresearchaiworkflowoverview.netlify.app/) + +<callout emoji="馃"> +**AI 鐮旂┒宸ヤ綔娴?*寤鸿涓嶈兘鍙湅鈥滆兘涓嶈兘鐢熸垚鍐呭鈥濓紝鏇村叧閿殑鏄?*鑳藉惁褰㈡垚绋冲畾鐨勭粍缁囩煡璇嗚祫浜?* +濡傛灉鍙槸璁?AI 鐢熸垚涓€浠藉垎鏋愭姤鍛婏紝鍏跺疄浠峰€兼湁闄愶紝鍥犱负鎶ュ憡鐪嬪畬涔嬪悗寰堝鏄撳啀娆℃矇娌°€傛妸璧勬枡杞垚缁撴瀯鍖栫煡璇嗗崱锛屽苟涓斿尯鍒?MECH / REPORT / ORG锛屼笉鍚岀爺绌剁粨璁哄氨鑳芥矇娣€鍒颁笉鍚岀煡璇嗗眰绾т腑锛屽悗缁彲浠ヨ妫€绱€佸鐢ㄣ€佸姣斿拰缁х画杩唬 +姝ゅ锛屽綋宸ヤ綔娴佽秺鏉ヨ秺澶嶆潅涔嬪悗锛屽緢澶氱姸鎬佸悕銆佺洰褰曡鍒欍€佸叆搴撴爣鍑嗐€乻hare 椤甸潰銆丠TML 椤甸潰銆丮arkdown 婧愭枃浠朵箣闂村緢瀹规槗涓嶄竴鑷淬€傚鏋滆繖浜涗笉缁熶竴锛屽悗缁洟闃熷叾浠栦汉浣跨敤鏃朵細浜х敓鍥版儜銆傚洜姝わ紝鍚庣画闇€瑕佺户缁妸鈥滆鍒欐樉鎬у寲鈥濓紝鍑忓皯渚濊禆涓汉璁板繂鍜屼复鏃跺垽鏂璡n</callout> + + + +# 涓夈€佸垱鏂扮粍鍏ㄦ爤 AI 寮€鍙戞柟鍚戞€濊€冨強宸ヤ綔娴佹惌寤篭n +鑳屾櫙锛歕n +浠婂ぉ闈㈣瘯鍊欓€変汉鏃朵簡瑙e埌鍏朵粬瓒呬紤闂插巶鍟?IAA 娓告垙锛堣鍘傚晢鑱氱劍鎺掑簭绫伙級鐨勭爺鍙戞墦娉曪細鍏冲崱璁捐銆佺珵鍝佹媶瑙c€佸帇鍔涙洸绾裤€佸叧鍗$畻娉曞鍒汇€佸揩閫熻凯浠g瓑鍐呭锛屽紩鍙戜簡鎴戝鍒涙柊缁勫綋鍓嶅伐浣滅殑杩涗竴姝ユ€濊€冦€傜敱浜庢垜瀵硅繖涓搧绫荤殑寮€鍙戞柟娉曘€佸叧鍗¤璁℃牳蹇冭兘鍔涘拰琛屼笟甯歌娴佺▼骞朵笉鐔熸倝銆傞潰璇曠粨鏉熷悗瀵逛紤闂?IAA 娓告垙寮€鍙戞柟娉曡繘琛屼簡鍒濇浜嗚В锛屽苟杩涗竴姝ユ€濊€冨垱鏂扮粍濡備綍鎶婅繖浜涜兘鍔涜浆鍖栦负 AI 鍏ㄦ爤寮€鍙戞祦绋嬬殑涓€閮ㄥ垎 + + + +### 浠庨潰璇曡幏寰楃殑鍚彂 + +鍊欓€変汉鎻愬埌鐨勮秴浼戦棽鍏冲崱璁捐鏂规硶涓昏鍖呮嫭锛歕n +1. 閫氳繃绔炲搧浣撻獙鎷嗚В鍏冲崱缁撴瀯 +2. 璁板綍鍏冲崱杩囩▼涓殑鐜╁鎿嶄綔鍜屽崱鐐筡n3. 缁樺埗绫讳技鍘嬪姏鏇茬嚎 / 蹇冩祦鏇茬嚎鐨勫垎鏋愬浘 +4. 鎺ㄦ祴绔炲搧鍏冲崱鐢熸垚閫昏緫鍜岀畻娉昞n5. 鍐嶅熀浜庢媶瑙g粨鏋滃仛鑷鍏冲崱璁捐鍜岃凯浠n +涓€寮€濮嬫垜涓嶇‘瀹氳繖浜涘仛娉曟槸鍚︿唬琛?*琛屼笟鏍稿績鑳藉姏**锛屽洜涓烘病鏈夊仛杩囪秴浼戦棽娓告垙锛屽緢闅惧垽鏂叾浠峰€笺€傞潰璇曠粨鏉熷悗杩涗竴姝ヤ簡瑙o紝褰㈡垚浜嗗嚑涓垽鏂細 + +- 瓒呬紤闂?/ 浼戦棽 IAA 鐨勬牳蹇冪珵浜夊姏骞朵笉鏄郴缁熷爢鍙狅紝鑰屾槸瀵?*鍗曠偣涔愯叮銆佸叧鍗¤妭濂忋€佸け璐ュ弽棣堛€佸箍鍛婅妭鐐瑰拰鏁版嵁杩唬**鐨?*宸ョ▼鍖栨帶鍒?* +- 鍊欓€変汉鎻愬埌鐨勨€滅珵鍝佹媶瑙?鈫?鍘嬪姏鏇茬嚎 鈫?绠楁硶澶嶅埢 鈫?鍏冲崱杩唬鈥濇柟鍚戞槸鎴愮珛鐨勶紝浣嗘瘮杈冨亸浼犵粺浜哄伐鏂瑰紡 +- 瀵瑰垱鏂扮粍鏉ヨ锛屾洿閲嶈鐨勬槸**鎬濊€冨浣曟妸杩欎簺浜哄伐缁忛獙杞寲涓?AI 宸ヤ綔娴佽祫浜?*锛屼緥濡傦細 + + - 绔炲搧鎷嗚В妯℃澘 + - 鍏冲崱鍙傛暟鍖栬〃杈綷n - AI 鐢熸垚閰嶇疆 + - 鑷姩鍖栨祴璇昞n - 鏁版嵁鍥炴祦 + - 澶嶇洏鎶ュ憡 + +**浼戦棽 IAA 鐨勪环鍊煎湪浜庡懆鏈熺煭銆佺郴缁熺浉瀵瑰彲鎺с€佸鏄撳舰鎴愰棴鐜紝閫傚悎璁粌灏忓洟闃熶粠鍒涙剰銆佽璁°€佷唬鐮併€佺編鏈€侀厤缃€佸箍鍛婄偣銆佸煁鐐瑰埌澶嶇洏鐨勭鍒扮鑳藉姏** + + + +### 鎼缓鍒涙柊缁勯暱鏈熷伐浣滃尯 + +**鎴樼暐鐮旂┒閮ㄥ垱鏂扮粍闀挎湡宸ヤ綔鍖?*锛歚/Users/dianchu/projects/strategy-innovation-lab` + +鍚庣画鍒涙柊缁勭浉鍏冲伐浣滈兘搴斿湪杩欎釜鐩綍涓嬫矇娣€锛屽寘鎷細 + +- 浼戦棽 / 瓒呬紤闂?IAA 娓告垙涓?AI 绠$嚎 +- Claude Code / OpenClaw / Cursor 绛夊叏鏍?AI 寮€鍙戝伐浣滄祦 +- 鑷姩鍖栨父鎴忓垎鏋愬伐鍏穃n- AI 鍘熺敓娓告垙 Demo 涓庡皬鍨嬪疄楠孿n- 鍐呴儴鐮旂┒鎶ュ憡 +- 鍒涙柊缁勪細璁邯瑕併€佹棩鎶ョ礌鏉愩€侀樁娈靛鐩榎n- 鍙鐢ㄦā鏉裤€丼OP銆丳rompt 涓庝笂涓嬫枃璧勪骇 + +![](https://internal-api-drive-stream.feishu.cn/space/api/box/stream/download/authcode/?code=ODY1MzAxOTU0OTNlZGJiMTBhNWEyZGU2MDM2NWMwNWVfZDJlZGE0N2JhNjAwNWJhYTkwYjdlOGVhNmIxZjYxOTdfSUQ6NzYzOTgzNjI5MzgxOTU1MDY4MF8xNzc5MTc2MTE0OjE3NzkxNzk3MTRfVjM) + + + +### 浜嗚В瓒呬紤闂?/ 浼戦棽 IAA 鏂规硶璁篭n +鍦ㄤ簡瑙e悗鏁寸悊浜嗕竴浠藉唴閮ㄦ寚鍗楋紝甯姪鍒涙柊缁勫缓绔嬪浼戦棽 / 瓒呬紤闂?IAA 娓告垙鐨勫熀纭€鐞嗚В锛屾牳蹇冨唴瀹瑰寘鎷細 + +1. 瓒呬紤闂叉父鎴忕殑瀹氫箟涓庢牳蹇冭璁$悊蹇礬n2. 琛屼笟閫氱敤鍏冲崱璁捐娴佺▼ +3. 涓嶅悓骞冲彴鍜屽搧绫讳笅鎸囨爣閫傜敤杈圭晫 +4. 绔炲搧鍏冲崱绠楁硶鍥涘眰鎷嗚В鏂规硶璁篭n5. 浠庝汉宸ユ媶瑙e埌 AI 绠$嚎鐨勬槧灏刓n6. AI 钀藉湴鐨勫垎闃舵璺嚎 +7. 鍒涙柊缁勫弻绾胯惤鍦版柟妗圽n8. 绗竴涓瘯楠屽搧绫婚€夋嫨寤鸿 +9. 宸ュ叿鏍堜笌鍒嗗伐 +10. 鍒涙柊缁勪竴椤垫墽琛岀増 + + + +鐐瑰嚮鏌ョ湅璇︽儏锛歔瓒呬紤闂叉父鎴忓叧鍗¤璁′笌AI绠$嚎鍐呴儴鎸囧崡 鈥?鎴樼暐鐮旂┒閮ㄥ垱鏂扮粍](https://jasminehuang477-cmd.github.io/share_hyper_casual_game_design_guide/#s10) + + + + + +### 瀵瑰綋鍓嶄簩鍚堢被 IAA 浠诲姟鐨勬€濊€僜n +浜屽悎绫讳笉鏄渶杞婚噺鐨勬柟鍚戙€傚鏋滃彧鎯抽獙璇佸叧鍗$敓鎴愮畻娉曪紝鎺掑簭绫绘洿鍚堥€傦紱濡傛灉鎯宠鍗曚汉绛栧垝鐢?AI 瀹屾垚涓€涓洿瀹屾暣鐨?IAA 浜у搧闂幆锛屼簩鍚堢被鏇村悎閫傘€備簩鍚堢被鐨勪紭鍔垮湪浜庯細 + +1. **鑳借鐩栨洿瀹屾暣鐨勪骇鍝佹ā鍧?*锛? + + - 妫嬬洏 + - 鍚堟垚 + - 鐢熸垚鍣╘n - 璁㈠崟 + - 鐗╁搧閾綷n - 骞垮憡鐐筡n - 鍩嬬偣 + - 缇庢湳 + - 娴嬭瘯涓庡鐩榎n2. **鏇撮€傚悎楠岃瘉 AI 閰嶇疆椹卞姩寮€鍙?*锛? + + - 鐗╁搧閾鹃厤缃甛n - 璁㈠崟閰嶇疆 + - 鐢熸垚鍣ㄩ厤缃甛n - 骞垮憡鐐归厤缃甛n - 鍩嬬偣浜嬩欢閰嶇疆 +3. **鏇撮€傚悎楠岃瘉 AI 缇庢湳鑳藉姏**锛? + + - 浜屽悎绫诲ぉ鐒堕渶瑕佹垚缁勭墿鍝佸浘鏍嘰n - 鍙互璁粌 Prompt 妯℃澘銆侀鏍肩粺涓€銆佹壒閲忕敓鎴愩€佺瓫閫夈€佸懡鍚嶃€佸鍏ュ伐绋嬬瓑娴佺▼ +4. **鏇撮€傚悎璁粌浜у搧闂幆鎰忚瘑**锛? + + - 涓嶅彧鏄仛涓€涓帺娉曪紝鑰屾槸瑕佸舰鎴愨€滃悎鎴?鈫?璁㈠崟 鈫?濂栧姳 鈫?骞垮憡鐐?鈫?鍩嬬偣 鈫?澶嶇洏鈥濈殑瀹屾暣閾捐矾 + +浣嗗畠鐨勯闄╀篃鏇撮珮锛歕n +- 绯荤粺鏁伴噺澶氾紝鍗曚汉寮€鍙戝鏄撳け鎺n- 鍚堟垚閾俱€佽鍗曡妭濂忋€佺敓鎴愬櫒浜ч€熶箣闂撮渶瑕佸钩琛n- AI 鑳界敓鎴愭ā鍧楋紝浣嗕笉鑳借嚜鍔ㄤ繚璇佷綋楠屾垚绔媆n- 缇庢湳铏界劧鏈夋垚鐔?AI 宸ュ叿锛屼絾椋庢牸涓€鑷存€у拰杈ㄨ瘑搴︿粛瑕佷汉宸ュ垽鏂璡n- MVP 杈圭晫涓嶈兘閿佹锛屼絾蹇呴』闃舵鎬ф敹鍙n + + +鐐瑰嚮鏌ョ湅璇︽儏锛歔浜屽悎绫?IAA 浜у搧椤圭洰浣滀负鍒涙柊缁勫叏鏍?AI 寮€鍙戝垏鍏ョ偣鐨勯€傞厤鎬ц瘎浼?鈥?鎴樼暐鐮旂┒閮ㄥ垱鏂扮粍](https://merge2iaa-selectionanalysis.netlify.app/) + + + +### 瀵瑰垱鏂扮粍绠$悊鐨勫惎鍙慭n +涓嶈兘鍙湅鍗曚釜椤圭洰鎴愯触锛岃€屽簲璇ョ湅澶氫釜鍚屽鐙珛寮€鍙戦」鐩悗褰㈡垚鐨勬í鍚戝姣斾环鍊笺€傚洜涓烘瘡浣嶅悓瀛﹂兘鏄嫭绔嬩娇鐢?AI 鍋氫竴涓」鐩紝鎵€浠ョ湡姝f湁浠峰€肩殑涓嶆槸绠€鍗曟瘮杈冣€滆皝鐨勪骇鍝佹洿濂解€濓紝鑰屾槸姣旇緝锛歕n +- 璋佺殑 AI 缂栨帓鏁堢巼鏇撮珮 +- 璋佺殑浜у搧闂幆鏇村畬鏁碶n- 璋佺殑 Prompt 鍜屽紑鍙戞祦绋嬫洿鍙鐢╘n- 璋佽兘鏇村ソ鎺у埗椤圭洰鑼冨洿 +- 璋佺殑閰嶇疆 Schema銆佺墿鍝侀摼銆佽鍗曡璁℃洿鍙矇娣€ +- 鍝簺澶辫触鍘熷洜鏄叡鎬х殑 +- 鍝簺鎴愬姛璺緞鍙互澶嶅埗 + +鍒涙柊缁勭殑闃舵澶嶇洏闄や簡浜у搧灞曠ず锛岃繕搴旇閲嶇偣杩涜 AI 宸ヤ綔娴佸鐩樸€傚寘鎷絾涓嶉檺浜庯細 + +- Prompt +- Schema +- 閰嶇疆妯℃澘 +- 宸ョ▼楠ㄦ灦 +- 缇庢湳鐢熸垚娴佺▼ +- 鍩嬬偣妯℃澘 +- 娴嬭瘯涓庡鐩樻柟娉昞n- AI 浣跨敤鏁堢巼鏁版嵁 + +<callout emoji="馃"> +鍗充娇鏌愪釜浜у搧椤圭洰澶辫触锛屽彧瑕佹矇娣€浜嗗彲澶嶇敤璧勪骇锛屼篃浠嶇劧鏈夌粍缁囦环鍊硷紱浣嗗鏋滃彧鏄け璐ヨ€屾病鏈夋矇娣€锛岄偅鎵嶆槸鐪熸鐨勫け璐n</callout> diff --git a/output/downloaded-files/html-md/2026-05-25_report_my_garden_world_us_project.html b/output/downloaded-files/html-md/2026-05-25_report_my_garden_world_us_project.html new file mode 100644 index 0000000..02a8b2d --- /dev/null +++ b/output/downloaded-files/html-md/2026-05-25_report_my_garden_world_us_project.html @@ -0,0 +1,959 @@ +<!DOCTYPE html> +<html lang="zh-CN"> +<head> +<meta charset="UTF-8"> +<meta name="viewport" content="width=device-width, initial-scale=1.0"> +<title>《我的花园世界》产品机制研究与产品策略参考 — 战略研究部 + + + +
+ + + + + +
+
+
机制判断
+
低压经营
极致消耗
公会异步任务型GVG
大通服
+
+
+
核心风险
+
题材画风吸量程度与购买欲
付费动机与付费意愿
社交路径与内容产能
+
+
+
下一步
+
题材画风买量测试
MVP分阶段验证
+
+
+ + +
+

目录

+ +
+ + +
+

一、核心结论

+ +
+

《我的花园世界》不是传统养成的轻量化版本,也不是纯休闲种花游戏。

+

它是一套把低压经营入口极致资源消耗公会异步任务型GVG横向收集展示大通服社交组合在一起的长线结构。

+
+ +
    +
  1. 极致的消耗模型。日常订单/任务接近无上限,玩家长期处于"有花但不够用"的状态。A
  2. +
  3. 公会竞赛是需求放大器。内部定义为"低协同、弱对抗、高覆盖、强分层、低焦虑的GVE型GVG"。它放大的是图鉴收集需求和资源用途优先级,而不是单纯增加消耗量。A+C
  4. +
  5. 付费玩家的社交角色是"被需要",而不是"压制别人"。付费买的是可见性、反馈性和社会比较,不是传统意义上的战力碾压。B+C
  6. +
  7. 大通服成立需要四层条件同时满足:消耗层、资产层、匹配层、时间层。C
  8. +
  9. 前期重点不是一次性展示全部系统,而是先让玩家觉得经营过程轻松、顺手、可随时回来,逐步形成日常习惯。A
  10. +
  11. 社交不是从公会才开始。雇佣、摸花、花贸市场等系统先让玩家接受"别人和我的经营有关"。A
  12. +
  13. 从低压经营到公会竞争,不是突然跳转,而是经过"低压习惯→低侵入交互→组织贡献"的渐进过程。C
  14. +
  15. 美国版应优先复刻机制结构,但必须验证题材画风、审美购买欲、社交路径、内容产能和买量效率C
  16. +
+
+ + +
+

二、产品结构:四层机制

+

产品定位:用低压经营入口获取泛用户,用公会组织竞争留住中重度用户并变现。经营养成+个人社交部分能单独成立。

+ +
+
+
第一层:低压经营入口
+
+ 种花、收花、订单、布置、收集
+ 前期完成习惯养成,让经营变成日常条件反射。不进公会也能形成完整循环。 +
+
+
+
第二层:横向收集和展示
+
+ 花灵、限定花、装饰、称号
+ 让付费更接近审美消费、收藏消费、为公会贡献消费,而不是传统个人战力提升。 +
+
+
+
+
+
第三层:公会异步任务型GVG
+
+ "低协同、弱对抗、高覆盖、强分层、低焦虑"
+ 异步任务制,每人有限次数,每周竞赛。把个人经营转译为组织贡献。 +
+
+
+
第四层:极致消耗引擎
+
+ 日常订单 + 活动任务 + 公会竞赛限时任务
+ 接近无限的订单持续消耗库存,竞赛驱动图鉴扩展和当期付费。玩家长期处于"有事可做、但永远不富余"的状态。 +
+
+
+ +
+ + +
+

三、极致消耗模型

+

本章解释:为什么玩家永远有事可做、永远缺资源,以及这套消耗是如何驱动付费的。

+ +

消耗结构

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
消耗出口消耗对象对谁有压力付费驱动
日常订单(居民/顾客/宫廷/组团)花材库存所有活跃玩家时间加速+花材补充
公会竞赛-中低难度任务花材库存(限时)平民/微氪加速+库存补充
公会竞赛-高分任务当期付费花中高R当期周花礼包/限定花购买
活动/限定任务特定花材+元宝追求限定内容的玩家活动礼包+加速
花灵/图鉴培育培育材料+时间收集型玩家培育加速+材料购买
+
+ +

持续消耗如何成立

+

玩家养成积累的是图鉴广度和种植效率,不是可部署的战力存量。订单系统持续消耗库存,玩家需要提前储备大量资源以应对不同任务,因此24小时都可以有事可做

+

当前怀疑系统存在根据玩家库存动态推送订单的机制,但这仍是C类推演,需要后续验证。C

+ +

非累计式任务:消耗设计的结构性保障 A

+

主线和活动任务中存在大量非累计式任务——每次都从零开始消耗资源,历史积累不能减免当次消耗。

+ + +

与Gossip Harbor的结构对比

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
维度Gossip Harbor花园世界
消耗瓶颈时间/能量库存品类
付费心理即时冲动型规划焦虑型
加速机制能量倍增器(x2/x4/x8)公会竞赛高分任务需要当期付费花
社交消耗层公会竞赛+组团订单
无底洞形态单层(个人速度)双层(日常库存+图鉴扩展)
+
+ +
+ + +
+

四、与传统养成对比

+

本章说明:花园世界和我们熟悉的传统养成项目有什么根本区别,为什么不能照搬传统养成的做法。

+ +

万岁爷运营引擎

+

每3天一轮,10轮 = 30天赛季。
每轮同时开启:数值冲榜 + 跨服副本 + 小游戏 + 促销 + 限时活动 + 外显投放。
底层逻辑:增量式强制消耗 + 多维数值轮转 + 榜单压力变现。

+ +

根本区别

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
维度传统养成(万岁爷)花园世界
核心驱动资源运营+个人PVP冲榜PVE收集经营+异步任务型GVG
数值结构存量数值长期有效,同时通过周期活动制造增量消耗图鉴广度、种植效率和库存消耗为主,弱化直接战力碾压
竞争方式个人榜单、跨服数值比拼公会竞赛、小范围段位、按实力贡献
氪金影响氪金→压制→平民被挤出氪金→收集展示+社交价值→被靠近
时间绑定3天/轮无休息日每周有限次数,时间自由
回归体验流失=落后,需换号或追赶零摩擦回归,缺席不惩罚
+
+ +
+
关键判断 [C]
+

把竞争单位从个人换成公会,把"我比你强"换成"我们队比他们队强",把"氪金=碾压"换成"氪金=被需要"

+
+ +
+ + +
+

五、六面承重墙

+

核心策略:不轻易改产品机制和数值设计。以下是复刻过程中不能走形的关键设计。

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
承重墙本质改错了会怎样
一、双层结构第一层独立成立,第二层驱动变现,两层衔接自然第一层太薄→留存崩;第二层太早→用户流失
二、竞赛是需求放大器放大图鉴收集需求;限时压力让库存不能松懈竞赛跟花种消耗脱钩→商业化断裂
三、氪金=被需要高氪跟普通玩家共生不对立加入数值碾压→大通服崩塌
四、每周+次数有限有目标但不绑每天,时间自由变日常→倦怠;次数无限→纯氪金竞赛
五、资产跟人走高流动+低损失+竞赛期锁定资产绑公会→被困→爆发性流失
六、大通服+小池匹配社交池大+竞争可控+永远不鬼服分服→鬼服;匹配不当→无竞争感
+
+ +

大通服成立的四层条件:C

+ + +
+ + +
+

六、从低压经营到公会竞争的渐进路径

+

本章说明:玩家是如何从纯单机种花一步步进入公会竞争的——不只是被社交吸引,更是因为公会能提供更多资源获取渠道。

+ +

前期:建立低压经营习惯 A

+ + +

资源需求递增:进入公会的真实驱动力 A

+

玩家进入公会的前期动力不是"想社交",而是资源不够用了,公会能提供更多获取渠道

+ +

也就是说:玩家发现"不加公会我资源来源更少"→自然产生加入动机。社交归属感是后期在公会待久了之后的副产物,不是前期驱动力。

+ +

低侵入交互:公会前的过渡铺垫 A

+

雇佣、摸花、花贸市场等系统不只是公会前置教学,它们本身就是独立成立的经营模块。但它们同时让玩家提前接受了一件事:"其他玩家能给我资源"。

+
    +
  1. 雇佣采珍珠:好友=资源产出节点
  2. +
  3. 摸花/互访:别人的花园=额外收益来源
  4. +
  5. 花贸市场:玩家间资源交换形成经济关系
  6. +
+

等到公会解锁时,玩家已经习惯了"别人对我有用",加入公会只是把这个逻辑升级为组织关系。

+ +

目标用户与设计策略 A

+

内部判断,《我的花园世界》的用户中包含宝妈、30+女性等低压经营用户,她们的核心需求是低门槛、低焦虑、低侵入社交。这类用户不会主动寻求公会竞争,但可以被资源需求逐步引导进入。

+

设计策略:先让玩家形成经营习惯→通过资源瓶颈让她们发现别人有用→通过公会资源优势让她们自愿加入→公会竞赛在已有经营循环里自然出现。社交归属感是留久了之后的结果,不是进入的原因。

+ +
+
关键约束
+

如果跳过中间的资源引导和轻交互铺垫,直接从种花进入公会竞赛,玩家会觉得突兀。

+

要复刻的是"经营习惯 → 资源需求递增 → 发现公会有用 → 组织贡献"这条渐进路径。

+
+ +
+ + +
+

七、设计红线与商业前提

+

不改机制,但限定运营和表达边界。

+ +

设计红线

+
+
美国版设计红线
+
    +
  1. 经营养成必须独立成立。
    不进公会的玩家也有完整体验和长期目标。
  2. +
  3. 限定花不垄断高价值任务。
    不买当期新花也能完成有意义的公会贡献。
    花园世界现有表现支持该结构具备可持续性,但美国版仍需监控。
  4. +
  5. 错过无严重惩罚。
    可以损失进度,但不论什么时候继续游戏,都应能获得正常体验。
  6. +
  7. 被公会踢的体验安全网默认做。
    包括重新匹配引导、资产无损告知、踢人确认流程。
  8. +
+
+ +

商业前提 C

+

审美与物件欲望必须本地成立。

+

经营对象必须让美国用户愿意长期收集、展示和付费。如果物件欲望不成立,公会竞赛仍能运转,但付费会变成纯任务压力而非主动消费。

+ +

商业化方向:购物感与社会地位价值

+

花园主题天然让付费感知更接近购物。"我买了一朵好看的花"比"我买了碾压别人的力量"更容易被休闲用户接受。

+

底层理论支撑 A:玩家付费买的核心不是数值,而是可见性、反馈性和社会比较

+ + +

治理责任

+

暂时交给玩家,不轻易改。花园世界把系统摩擦转化为玩家间社交动力。

+

上线后需监控:

+ +
+ + +
+

八、行业趋势:休闲入口嫁接中重度运营

+

以Gossip Harbor为代表,叠加X+SLG、柠檬微趣旗下多款产品等案例,"休闲入口+中重度运营"在美国市场不是偶然现象,而是已被多类产品反复验证的出海方向B+C

+ +

Gossip Harbor核心数据 B

+ + +

当前竞争焦点 B+C

+

"休闲入口+中重度运营"方向已进入多产品竞争阶段,差异化不再是方向选择,而是执行细节。当前竞争集中在:

+ + +

对美国版的启发 C

+
    +
  1. 欧美休闲用户可以接受中重度运营,但前提是底层手感顺滑
  2. +
  3. 活动内容产能是生死线,高频活动直接影响收入增长
  4. +
  5. 核心玩法和数值底座必须足够有弹性,能承载活动堆叠而不让经济崩溃
  6. +
  7. 花园世界比Gossip Harbor多一层社交竞争,同样做极致消耗,但多了组织目标和社群认可
  8. +
+ +
+

花园世界和Gossip Harbor的核心差异不在消耗深度——两者都是无底洞。

+

差异在于:花园世界把"个人资源无底洞""组织贡献理由"接在一起,让持续消耗更容易被理解为经营目标、社交贡献和展示价值。

+
+ +
方向已被验证可行,关键在于我们的手感、产能和买量闭环能不能跟上已有竞品。
+
+ + +
+

九、MVP验证与失败判据

+

分阶段验证,每段有失败判据。

+ +

阶段0:题材画风与买量素材验证(前置/并行)

+
+
+
验证问题
+
    +
  • 美国用户是否被经营对象、画风和视觉钩子吸引
  • +
  • 买量成本相较其他产品是否有优势
  • +
  • 题材能否支撑持续活动素材产出
  • +
+
+
+
验证方式
+
    +
  • 静态图/短视频素材测试
  • +
  • 多题材、多画风、多视觉钩子对比
  • +
  • 与公司其他产品做成本对照
  • +
  • 发行、中台、研发共同复盘
  • +
+
+
+
失败判据
+
    +
  • 素材点击和转化明显弱于对照组
  • +
  • 买量成本无法支撑长线运营
  • +
  • 题材能吸量但无法支撑经营和公会任务
  • +
+
+
+ +

阶段1至3

+
+
+ 阶段1
低压经营
+
验证问题是否愿意种、收、布置?习惯是否养成?
+
验证方式核心循环原型测试
+
失败判据D1/D3留存不达标、玩家对种花和收集没有持续兴趣 → 题材手感不成立
+
+
+ 阶段2
经营→公会
+
验证问题是否理解"我种的东西能帮公会"?低侵入交互是否建立?
+
验证方式最小公会原型 + 低侵入交互系统
+
失败判据不理解关联、觉得公会突兀 → 渐进路径缺失
+
+
+ 阶段3
公会放大购买欲
+
验证问题付费动机是"喜欢+贡献"还是"怕拖累"?
+
验证方式完整竞赛 + 商店封测
+
失败判据公会任务未能让玩家产生"我想买当期新花"的欲望,而是产生"不买就跟不上"的压力 → 需求放大器变成了付费压迫器
+
+
+
+ + + + +
+ + diff --git a/output/downloaded-files/html-md/2026-05-yunhu-project-selection-strategy-report.html b/output/downloaded-files/html-md/2026-05-yunhu-project-selection-strategy-report.html new file mode 100644 index 0000000..31133d2 --- /dev/null +++ b/output/downloaded-files/html-md/2026-05-yunhu-project-selection-strategy-report.html @@ -0,0 +1,712 @@ + + + + + +广州云湖工作室项目选择策略报告 — 战略研究部 + + + +
+ + + +
+
+
第一优先
+
《我的花园世界》
欧美化花园 / 庄园 / 花店经营养成
+
+
+
关键判断
+
时间约束下综合适配度最优,非商业化确定性最高
+
+
+
最大待验证项
+
花园方向商业化深度待深拆验证
+
+
+
决策窗口
+
2 周内基于数据锁定方向
+
+
+ +
+

目录

+
    +
  1. 一、报告目标与判断口径
  2. +
  3. 二、关键参照案例定位
  4. +
  5. 三、候选方向评估
  6. +
  7. 四、方向选择的关键分歧与独立判断
  8. +
  9. 五、推荐排序与验证策略
  10. +
  11. 六、团队配置与执行节奏
  12. +
  13. 七、信息缺口与后续研究任务
  14. +
  15. 八、结论
  16. +
+
+ + +
+

一、报告目标与判断口径

+

本报告为广州云湖工作室第一个转型项目的方向选择提供结构化分析和推荐排序。

+

判断口径

+ +

来源标注

+

本报告对所有判断标注来源层级:

+ +
+ + +
+

二、关键参照案例定位

+ +

2.1 公司传统养成产品

+

涵盖产品:《叫我万岁爷》《Game of Sultans》《Game of Khans》《Vikingard》

+
+
核心认知
+ 公司最成功养成产品的本质是"泛用户 / 女性高占比导入 + 深养成商业化",而非"男性历史帝王模拟"。内部经验 +
+ +

可复用资产:活动模板、排行榜、公会竞赛、资源消耗与加速、礼包直售、分组撮合、付费玩家分层、长线运营排期 内部经验

+

约束:代码较难直接复用 内部共识;旧式历史帝王包装和画风不适合直接复用,需针对目标市场重新设计 内部经验

+ +

《King's Choice》的补充意义

+

《King's Choice》仅作为案例引用,不作为候选方向。它说明以下几点:

+
    +
  1. GOS 类传统养成通过欧美化题材、画风和素材包装,可在美国市场取得可观用户规模和流水 内部经验
  2. +
  3. 单一美国市场容量足够大 内部经验
  4. +
  5. 美术包装、题材包装和素材表达对养成出海结果影响巨大 内部经验
  6. +
+
+ 其价值在于证明"欧美化包装可以放大 GOS 类养成在美国市场的可接受度",而不是提供云湖当前可直接复刻的产品方案。不因此案例直接推导云湖应做同类产品,不自动提高"欧美化历史养成"推荐权重。 +
+ +

2.2 《我的花园世界》/《My Garden Tale》

+

定位:方向成立的市场参照,用于验证偏单机的轻经营养成,在基于消耗模型引入 GVG 后,采用先进匹配撮合机制的长线可行性。

+ +
+
使用边界
+ 可作为方向验证参照,不能直接作为商业化模板照搬。商业化结构尚未完成系统深拆,头部付费深度、收入结构、地区差异和真实鲜花机制贡献仍需通过数据平台和深度拆解确认。待验证 +
+ +

2.3 延趣等快速换皮团队

+

定位:竞争基线和时间参照。

+ +
+ + +
+

三、候选方向评估

+ +

评估维度

+
+ + + + + + + + + + + + + +
#维度说明
12 个月开发 + 第 3 个月测试以当前 16 人 + AI 工具为基线
216 人团队适配度当前编制能否支撑,是否需新增关键能力
3AI 小团队提效空间哪些环节 AI 已可替代、哪些仍需人工
4公司养成商业化复用度活动、排行、竞赛、资源消耗模板能复用多少
5美国市场素材吸量潜力题材理解成本、文化摩擦、素材钩子强度
6素材与玩法一致性广告导入的用户预期是否与游戏体验匹配
7留存与商业化承接难度首日体验、核心循环、付费动机清晰度
8失败后资产复用度代码、美术、管线能力能否迁移到下一个方向
9需要新增能力的程度当前团队缺什么、补齐难度和时间成本
+
+
+ + +
+

第一优先 方向 1:欧美化花园 / 庄园 / 花店经营养成

+

定义:以花园种植、庄园修复、花店经营为主题,围绕"种植-培育-收集-竞赛-消费"构建主循环,面向欧美泛用户 / 女性用户,以低文化摩擦的轻松治愈风格包装获客。

+ +

推荐理由

+

本方向排在第一优先,不是因为商业化确定性最高,而是因为在云湖当前 16 人团队、2 个月开发、第 3 个月上线测试、AI 小团队适配的约束下,它的综合适配度更优:

+ + +

主要风险

+
    +
  1. 商业化深度尚未经系统验证——头部付费能力可能弱于历史养成 待验证
  2. +
  3. 美国市场轻经营花园品类竞品密度未知,可能同质化 待验证
  4. +
  5. 真实鲜花机制有履约成本、地区覆盖和客服风险,不能作为唯一差异化 内部经验
  6. +
  7. 过度商业化可能影响轻松治愈体验感,但该风险整体可控 分析推断
  8. +
  9. 公司养成商业化模板嫁接方式需针对花园品类适配 分析推断
  10. +
+ +

成立条件

+ + +

否决条件

+ + +

验证方式

+ +

该方向不是商业化确定性最高的方向,但在当前时间、团队和 AI 小团队约束下,是交付确定性最高、验证成本最低、失败后资产复用度最高的首选验证方向。

+
+ + +
+

第一梯队备选 方向 2:欧美化泛用户历史 / 家族 / 宫廷养成

+

定义:以中世纪王权、贵族、家族继承、宫廷关系为题材,围绕"历史成长-伴侣-子嗣-联盟-排行-竞赛"构建主循环,以泛用户 / 女性情绪素材获客,承接公司成熟养成商业化模板。

+ +

推荐理由

+

本方向是商业化确定性更高、公司经验复用更强的第一梯队备选:

+ +
+ 如果能在 1 周内获得厦门成熟养成经验的结构化输入,并完成系统裁剪(确定极简 MVP 范围),则可以进入与花园方向的并行验证。 +
+ +

主要风险

+
    +
  1. 系统复杂度高于花园经营——2 个月出 MVP 挑战性大 分析推断
  2. +
  3. 角色美术精度要求可能更高,AI 能否达标待验证 待验证
  4. +
  5. 同类产品已有占位者,差异化难度 分析推断
  6. +
  7. 短周期交付风险高于花园方向 分析推断
  8. +
  9. 厦门成熟养成经验迁移存在不确定性 待验证
  10. +
+ +

成立条件

+ + +

否决条件

+ + +

验证方式

+ +
+ + +
+

备选 方向 3:宠物 / 奇幻生物 / 轻培育经营

+

定义:将花园经营的"种植-培育-收集-竞赛"迁移到宠物、奇幻生物方向。

+

推荐理由

+ +

主要风险

+ +

否决条件

+ +
+ + +
+

低优先 方向 4:小镇 / 咖啡馆 / 烘焙 / 餐厅轻经营

+

题材低门槛但同质化极高,商业化深度可能不足,差异化难度大。仅在上述方向均不成立时考虑。

+
+ + +
+

有条件探索 方向 5:生存 / 末日 / 避难所轻经营

+

生存 / 末日市场已验证可作为买量入口素材,需在玩法包装上做完整适配设计,因而会增加项目不确定性。内部经验

+

仅在玩法本体就是生存经营、营地建设、资源短缺、幸存者管理时成立;否则素材 / 游戏预期落差将损害留存。内部经验

+
+ + +
+

暂不推荐 方向 6:古风经商 / 男性资产收集 / 其他

+

美国市场文化摩擦高、男性题材拉高玩法预期、预估获客成本及留存风险较高。仅在所有前述方向均被否决时重新评估。

+
+ + +
+

四、方向选择的关键分歧与独立判断

+ +

4.1 花园经营 vs 历史养成:时间可控性 vs 商业化确定性

+
+ + + + + + + + + + +
维度花园 / 庄园经营历史 / 家族养成
2 个月出版本可能性高(系统轻、模块少)挑战较大(伴侣/子嗣/联盟系统多)
商业化深度待深拆验证更确定(公司有完整模板和历史数据)
外部经验依赖参照花园世界但非照搬需厦门隐性经验快速结构化迁移
AI 美术适配2D 插画 / 轻松治愈风格,AI 高效角色精度更高,AI 达标待验证
失败后残值可迁移到宠物 / 小镇方向商业化模板可迁移到其他养成方向
竞品格局品类竞品多但门槛低已有占位者,但品类天花板高
+
+ +

4.2 厦门成熟经验迁移的可行性

+
+
关键判断
+ 云湖项目能否成立,很大程度取决于厦门成熟养成项目的经验、商业化方法和隐性认知能否被快速结构化、模板化,并迁移到云湖小团队中。 +
+

这不是简单的"复制策划案",而是对以下隐性认知的系统性迁移:

+ +

如果这些经验能在 1–2 周内完成结构化输出,则历史养成方向可行性显著提升。如果无法快速迁移,则时间风险进一步放大。

+ +

4.3 综合判断

+ +
+ + +
+

五、推荐排序与验证策略

+ +

5.1 推荐排序

+
+ + + + + + + + + + +
优先级方向定位关键判断依据
第一优先欧美化花园 / 庄园 / 花店经营养成首选验证方向时间可控 + 参照产品表现稳定 + AI 适配度高 + 低复杂度 + 资产可复用
第一梯队备选欧美化泛用户历史 / 家族 / 宫廷养成商业化更确定,交付风险更高视厦门经验迁移可行性和 MVP 裁剪结果
备选宠物 / 奇幻生物 / 轻培育经营花园方向近亲替代花园素材测试不理想时快速切换
低优先小镇 / 咖啡馆 / 烘焙 / 餐厅差异化困难仅在上述方向均不成立时考虑
有条件探索生存 / 末日 / 避难所轻经营需玩法本体契合可作为其他方向的买量素材测试
暂不推荐古风经商、男性资产收集等与核心约束冲突仅在所有前述方向均被否决时重新评估
+
+ +

5.2 验证策略:两周决策窗口

+

第 1 周并行执行

+ +

第 2 周决策

+ +
+ + +
+

六、团队配置与执行节奏

+ +

6.1 16 人团队通用分工原则

+ + +

6.2 花园方向下的建议分工

+
+ + + + + + + + + + + +
模块人力主要职责
制作人 / 项目负责人1控范围和节奏,对上线和数据负责
商业化 / 活动策划2复用养成竞赛、礼包、排行、资源售卖模板
系统 / 数值策划1种植-培育-收集-竞赛主循环和资源产销
包装 / 留存策划1美国市场包装、素材承接、首日体验
程序 / AI 管线4–5管线搭建、智能体维护、服务端、数据
美术 / UI / AI 资产4–5风格统一、AI 出图、UI/UX、关键素材
支持 / QA1配置验收、自动化测试
+
+ +

6.3 执行节奏

+
+ + + + + + + + +
阶段时间核心产出止损检查
第 0 阶段:方向验证第 1–2 周素材数据 + 商业化深拆 + 方向决策所有素材 CPI 均超标 → 重评市场
第 1 阶段:核心开发第 3–6 周主循环可玩 + 商业化基础模块第 5 周核心循环未跑通 → 缩减 MVP
第 2 阶段:完整 MVP第 7–8 周内部可验收版本 + 商店素材第 8 周无法完成 → 延期 1 周或砍系统
第 3 阶段:上线测试第 9–12 周第 9 周起小规模上线测试,根据投放数据和首轮留存/付费表现快速迭代D1 留存 / 首付率低于阈值 → 诊断问题
+
+ +

6.4 关键决策节点

+ +
+ + +
+

七、信息缺口与后续研究任务

+
+ + + + + + + + + + + + +
缺口对决策的影响获取方式紧急度
《我的花园世界》商业化结构深拆直接影响花园方向是否成立深度体验拆解 + 数据平台 + 竞品横向对比本周
厦门养成项目成熟经验及隐性认知的迁移难度影响历史养成方向可行性,及花园方向商业化嫁接质量厦门核心策划/运营/数值访谈;老项目活动模板整理;典型活动复盘;付费结构与资源消耗模型拆解;关键坑点清单;可复用模板沉淀本周
美国市场花园/庄园品类 CPI 基线影响回收测算和方向选择发行侧数据 + 数据平台本周
美国花园/轻经营同类竞品密度影响差异化难度市场调研 + App Store 品类扫描本周
当前团队 AI 管线实际打通程度影响 2 个月开发可行性内部技术评估 + 管线 demo 验证本周
My Garden Tale 北美实际表现验证花园方向出海成绩Sensor Tower / data.ai1–2 周
真实鲜花机制可行性和 ROI影响花园方向获客差异化专题调研(履约成本、地区覆盖、物流、用户反馈)2 周内
美术 AI 出图效率验证影响 2 个月美术产能内部 AI 美术管线测试1 周
+
+
+ + +
+

八、结论

+ +

综合推荐

+

在云湖当前 16 人团队、2 个月开发 + 第 3 个月上线测试、AI 小团队、美国市场优先的约束下:

+
    +
  1. 欧美化花园 / 庄园 / 花店经营养成为第一优先验证方向——不是因为商业化确定性最高,而是因为系统复杂度、AI 适配度、素材测试效率和失败后资产复用度的综合适配最优。
  2. +
  3. 欧美化泛用户历史 / 家族 / 宫廷养成为第一梯队备选——商业化确定性更高,公司经验复用更强,但短周期交付风险更大。若厦门成熟经验可在 1 周内完成结构化迁移,应与花园方向并行验证。
  4. +
  5. 方向选择应在 2 周内基于数据决策——素材测试 + 商业化深拆 + 经验迁移评估三线并行,第 2 周末锁定唯一主方向进入全力开发。
  6. +
+ +

立即需要执行的事项

+
+
下一步行动
+
1
启动多方向素材投放测试(花园 / 历史 / 宠物各 2–3 组素材)
+
2
启动《我的花园世界》商业化结构深拆
+
3
启动厦门成熟养成经验访谈和模板整理
+
4
启动 AI 美术管线风格验证(欧美轻松治愈花园风格)
+
5
启动美国花园 / 庄园品类竞品密度扫描
+
+ +

报告有效期

+

本报告基于 2026 年 5 月 20 日的信息状态。以下情况触发报告更新:素材测试数据回收后;《我的花园世界》商业化深拆完成后;厦门经验迁移评估完成后;团队 AI 管线实际验证完成后;任何方向触发否决条件时。

+
+ + + +
+ + \ No newline at end of file diff --git a/output/downloaded-files/html-md/game-analyst-agent-manual.html b/output/downloaded-files/html-md/game-analyst-agent-manual.html new file mode 100644 index 0000000..252fd7e --- /dev/null +++ b/output/downloaded-files/html-md/game-analyst-agent-manual.html @@ -0,0 +1,1305 @@ + + + + + +game-analyst-agent 工具说明书 — 战略研究部 + + + +
+ + + + + +
+
+
核心能力
+
+ 自动探索界面
+ 机制规则提取
+ 数值事实采集
+ 多游戏横向对比
+ 活动变化追踪
+ 决策报告生成 +
+
+
+
覆盖范围
+
+ Android 游戏(模拟器)
+ H5 / 网页游戏
+ 竞品官网
+ 市场数据页面 +
+
+
+
使用方式
+
+ 命令行启动
+ 挂机无人值守
+ 定期查看增量报告
+ 按需生成决策报告 +
+
+
+
运行成本
+
+ 探索阶段:免费
+ 分析阶段:国产模型
+ 24h 连续运行 < 1 元 +
+
+
+ + +
+

目录

+ +
+ + +
+

一、工具定位与设计理念

+

为什么需要这个工具,它解决什么问题,不做什么。

+ +

1.1 解决的核心问题

+

游戏分析师在做竞品深拆、项目选型调研时,需要大量时间手动体验游戏、截图记录、整理机制规则、采集市场数据、横向对比。一款中度游戏的完整系统拆解通常需要 3-5 天人工投入,多游戏对比更是倍数级工作量。

+

game-analyst-agent 将整条分析链路自动化:

+ + +
+
设计理念
+ 工具定位是产品分析自动化辅助,不替代人工判断。它负责把信息「采集、结构化、对比、呈现」,分析师负责基于这些信息做商业判断和策略建议。 +
+ +

1.2 核心设计原则

+ + +

1.3 不做什么

+ +
+ + +
+

二、核心能力总览

+

工具当前已具备的全部能力,分为六大模块。

+ +
+
+
自主界面探索
+
+ Android 模拟器 + 浏览器双模式
+ 感知哈希去重,不重复探索
+ BFS 导航 + 自动回退
+ 长按 / 悬停 / 边缘抽屉发现
+ 弹窗自动关闭 + Cookie 处理
+ 自适应无限滚动 + 暗色主题适配 +
+
+
+
机制规则 + 数值提取
+
+ AI 视觉模型分析截图
+ 提取规则并按系统模块分类
+ 提取数值事实(定价/时间/消耗量)
+ 资源流转拓扑自动推断 +
+
+
+
多游戏横向对比
+
+ 跨游戏规则按 module 对齐
+ 自动标注差异点
+ 生成 HTML 对比矩阵报告 +
+
+
+ +
+
+
活动追踪与时间线
+
+ 定时重跑检测界面变化
+ 追踪限时活动上下线
+ 输出变化时间线 +
+
+
+
市场数据采集
+
+ 浏览器模式采集数据页面
+ 七麦 / SensorTower / 榜单
+ 补充市场表现维度 +
+
+
+
决策报告生成
+
+ 多游戏数据 + AI 综合分析
+ 面向管理层的推荐格式
+ 可直接用于项目评审会 +
+
+
+ +

2.1 探索智能(v1.7)

+

探索引擎内置 9 级优先级决策链,模拟真实用户的全部交互行为:

+
+
+
交互覆盖
+
+ 点击(tap)+ 长按(long press)
+ 垂直/水平滚动 + 自适应无限滚动
+ 边缘抽屉滑动(侧边栏/下拉面板)
+ 浏览器悬停(hover)展开子菜单 +
+
+
+
干扰处理
+
+ 弹窗自动检测 + 关闭(签到/活动/礼包)
+ Cookie/隐私同意弹窗自动关闭
+ 加载动画等待(画面稳定再操作)
+ 暗色主题自适应检测阈值 +
+
+
+
覆盖率保障
+
+ 角落小图标检测(?/!/设置)
+ Tab 栏等距按钮检测
+ DOM 元素精确识别(浏览器模式)
+ pHash 变化驱动的自适应决策 +
+
+
+ +

2.2 基础支撑能力

+
+
+
多模型后端
+
+ Claude / 通义千问 / GLM-4V / 豆包
+ 按需切换成本与精度 +
+
+
+
规则去重与分类
+
+ 自动去除重复规则
+ 按 module 分组归档
+ 置信度分层标注 +
+
+
+
容错与恢复
+
+ ADB 断连自动重连
+ API 失败重试后跳过
+ 探索引擎自动回退不卡死 +
+
+
+ +

2.3 完整工作流程

+
┌──────────────────────────────────────────────────────────────┐ +│ 单游戏深拆链路 │ +├──────────────────────────────────────────────────────────────┤ +│ │ +│ explore(Android / 浏览器) │ +│ │ │ +│ ├─ 探索阶段(本地,成本 = 0) │ +│ │ 截图 → pHash 去重 → 9 级智能决策: │ +│ │ 弹窗关闭 → 边缘抽屉 → tap → 滚动 → 自适应滚动 │ +│ │ → 长按 → 悬停(浏览器) → 回退 │ +│ │ │ +│ ├─ 分析阶段(定时,可控成本) │ +│ │ 批量截图 → AI 视觉模型 → 规则 + 数值事实 → DB │ +│ │ → 资源流转推断 │ +│ │ │ +│ └─ 报告阶段(自动) │ +│ 每 30min → 进度报告 | 探索结束 → 最终报告 │ +│ │ +└──────────────────────────────────────────────────────────────┘ + +┌─────────────────────────────────────────────────────────┐ +│ 多游戏对比 + 决策链路 │ +├─────────────────────────────────────────────────────────┤ +│ │ +│ compare → 跨游戏规则对齐 → 差异标注 → 对比报告 HTML │ +│ timeline → 定时重跑 → 活动上下线检测 → 变化时间线 │ +│ market → 浏览器采集数据页 → 市场数据补充 │ +│ decision-report → 多游戏数据 + AI 综合推断 → 决策报告 │ +│ │ +└─────────────────────────────────────────────────────────┘
+
+ + +
+

三、技术架构

+

工具的内部结构,供技术背景的使用者了解运行原理。非技术用户可跳过本节,不影响正常使用。

+ +

3.1 模块架构

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
模块文件职责
设备驱动core/adb_device_driver.py通过 ADB 控制模拟器:截图、点击、长按、滑动、返回
探索引擎core/explorer.py9 级优先级决策引擎:弹窗→抽屉→tap→滚动→自适应滚动→长按→回退
画面去重core/screen_dedup.py感知哈希(pHash)计算、Screen 库持久化、重复判定
本地检测core/local_detector.py视觉检测按钮/色块/Tab 栏/角落图标/弹窗覆盖层,暗色主题自适应
模型后端core/llm_backend.py统一接口调用多种视觉 AI 模型(OpenAI 兼容 + Anthropic)
批量分析core/batch_analyzer.py定时收集新截图、调用模型提取规则、写入数据库
报告生成core/reporter.py增量进度报告 + 最终完整报告生成
数据存储core/db_client.pySQLite 数据库:screens / rules / facts / sessions 表
浏览器驱动core/browser_driver.pyPlaywright 驱动:截图、点击、滚动、长按、悬停、DOM 感知、Cookie 弹窗处理
数值提取core/fact_extractor.py从 AI 分析结果中解析结构化数值事实
资源流转core/flow_inferrer.py从 rules + facts 推断资源流转拓扑关系
CLI 入口tools/cli.py命令行路由:explore / compare / timeline / market / decision-report / report / doctor / init
+
+ +

3.2 两阶段成本分离

+
+
+
探索阶段
+
纯本地运算:OpenCV 视觉检测 + pHash 去重 + 9 级智能决策 + 设备操作。成本 = 0,可无限运行。
+
+
+
分析阶段
+
定时批量调用视觉模型。使用国产模型(通义千问)时,24 小时连续分析成本 < 1 元人民币。
+
+
+ +

3.3 数据存储结构

+
SQLite 数据库(games/{game_id}/db/mechanics.db) +├── screens 界面库:phash、访问次数、深度、分析状态 +├── rules 机制规则:规则文本、module 分类、置信度、来源截图 +├── facts 数值事实:属性名、数值、单位、关联系统 +├── resource_flows 资源流转:source → target、消耗量、触发条件 +└── sessions 运行记录:时长、发现界面数、规则数、成本
+
+ + +
+

四、安装与环境配置

+

从零开始,3 分钟完成安装。

+ +

4.1 前提条件

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
依赖要求说明
操作系统Windows 10/11(推荐)Windows 推荐;macOS 需额外配置模拟器
Python3.10 或更高推荐使用 uv 安装管理
Android 模拟器MuMu Player 12(推荐)需开启 ADB 调试,默认端口 16384
模型 API Key至少一个推荐阿里通义千问(性价比)或 Anthropic Claude(精度)
+
+ +

4.2 安装步骤

+
+
安装流程
+
+
1
+
获取代码:git clone <repo_url> 然后 cd game-analyst-agent
+
+
+
2
+
安装依赖:pip install -e .(基础安装)或 pip install -e ".[all]"(含浏览器模式 + 定时任务)
+
+
+
3
+
配置 API Key:cp .env.example .env,用文本编辑器打开 .env,填入你的 Key
+
+
+
4
+
环境自检:game-analyst doctor,全部 ✓ 表示就绪
+
+
+ +
+
可选依赖说明
+
    +
  • pip install -e ".[browser]" — 安装 Playwright,启用浏览器模式和市场数据采集
  • +
  • pip install -e ".[schedule]" — 安装 croniter,启用定时重跑功能
  • +
  • pip install -e ".[all]" — 安装全部可选依赖
  • +
+
+ +

4.3 API Key 获取方式

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
模型供应商环境变量名获取地址参考价格
阿里通义千问-VLDASHSCOPE_API_KEYdashscope.aliyun.com约 0.003 元/张
字节豆包 VisionARK_API_KEYvolcengine.com/product/ark约 0.002 元/张
智谱 GLM-4VZHIPU_API_KEYopen.bigmodel.cn约 0.005 元/张
Anthropic ClaudeANTHROPIC_API_KEYconsole.anthropic.com约 0.02 元/张
+
+ +
+
推荐配置
+ 日常使用选阿里通义千问,成本极低且精度满足规则提取需求。需要高精度推断(如商业化结构分析)时切换 Claude。 +
+
+ + +
+

五、使用指南

+

从启动到查看报告的完整操作流程。

+ +

5.1 初始化游戏

+
game-analyst init --game my_garden + +# 输出: +# 已创建游戏配置:games/my_garden/ +# 请编辑 games/my_garden/game.yaml 填写游戏名称和设备信息
+

打开 games/my_garden/game.yaml,只需修改游戏名称:

+
game: + name: "我的花园世界" + id: my_garden + +device: + serial: "127.0.0.1:16384" # MuMu 默认端口
+ +

5.2 启动探索

+
# 确保模拟器已打开,游戏已进入主界面 + +# 启动(默认 24h 运行,每 30min 输出报告) +game-analyst explore --game my_garden + +# 自定义参数 +game-analyst explore --game my_garden \ + --max-runtime 4 \ + --analysis-interval 15 \ + --max-depth 8
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
参数说明默认值
--game游戏 ID(对应 games/ 下的目录名)必填
--deviceADB 设备地址127.0.0.1:16384
--max-runtime最大运行时长(小时)24
--analysis-intervalAI 分析触发频率(分钟)30
--max-depth探索最大深度(从主界面算起的层级数)6
--analyze-only只对已有截图重新分析,不启动探索关闭
+
+ +

5.3 查看进度

+
# 命令行查看状态 +game-analyst status --game my_garden + +# 直接读报告文件 +cat reports/my_garden/latest_progress.md
+ +

5.4 生成最终报告

+
# Markdown 格式(按系统模块分章节) +game-analyst report --game my_garden + +# HTML 格式(可直接发给非技术用户浏览) +game-analyst report --game my_garden --format html --standalone
+ +

5.5 完整 CLI 命令一览

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
命令用途使用场景
game-analyst explore启动自主探索挂机跑游戏/网页深拆
game-analyst status查看当前探索状态中途了解进度
game-analyst report生成/重新生成分析报告探索结束后导出最终报告
game-analyst compare多游戏横向对比报告对比多款游戏的机制/商业化结构
game-analyst timeline活动追踪与变化时间线定时重跑后查看竞品活动上下线
game-analyst market市场数据采集通过浏览器采集七麦/SensorTower 等页面数据
game-analyst decision-report决策报告生成基于多游戏数据生成面向管理层的推荐报告
game-analyst doctor环境自检首次安装或排查问题
game-analyst init初始化新游戏配置分析一款新游戏/网站前
+
+ +

5.6 多游戏对比

+

当你已对多款游戏完成探索后,可以生成横向对比报告:

+
# 对比 3 款游戏的商业化和核心循环 +game-analyst compare --games my_garden,merge_mansion,gardenscapes \ + --dimensions monetization,core_loop,progression + +# 只对比商业化维度 +game-analyst compare --games my_garden,merge_mansion --dimensions monetization
+

输出为 HTML 格式对比报告,包含:各游戏按 module 对齐的规则矩阵、差异点标注("A 有但 B 无")、各维度优劣小结。可直接发送给同事在浏览器中查看。

+ +

5.7 浏览器模式探索

+

对网页游戏、竞品官网或市场数据页面进行探索分析:

+
# 探索 H5 网页游戏 +game-analyst explore --game h5_game --driver browser --url "https://game.example.com" + +# 采集市场数据页面 +game-analyst market --game my_garden --url "https://www.qimai.cn/app/..." --headless
+

浏览器模式自动利用 DOM 结构精确识别可交互元素,覆盖率高于纯视觉检测。需安装可选依赖:pip install game-analyst-agent[browser]

+ +

5.8 活动追踪与时间线

+
# 查看最近 7 天的变化记录 +game-analyst timeline --game my_garden --last 7 + +# 输出为 HTML 格式 +game-analyst timeline --game my_garden --last 30 --format html
+

需先对同一游戏进行过多次探索(不同日期),工具会自动对比各次结果,标注新增/消失的界面和规则。

+ +

5.9 决策报告

+
# 生成面向管理层的项目选型支撑报告 +game-analyst decision-report \ + --games my_garden,merge_mansion,gardenscapes \ + --question "花园经营赛道哪款产品的商业化结构最适合小团队复制"
+

输出 HTML 格式决策报告:结论先行 + 对比矩阵 + 数据支撑 + 风险提示 + 建议。可直接用于项目评审会。

+
+ + +
+

六、输出产物说明

+

工具运行后产出哪些文件,各自的用途和阅读方式。

+ +

6.1 目录结构

+
game-analyst-agent/ +├── games/ +│ └── my_garden/ +│ ├── game.yaml 游戏配置 +│ ├── db/mechanics.db SQLite 数据库(规则、截图索引、运行记录) +│ ├── screenshots/explore/ 探索模式截图(按 pHash 命名) +│ └── logs/ 运行日志 +├── reports/ +│ └── my_garden/ +│ ├── latest_progress.md 最新增量进度报告(每 30min 更新) +│ └── final_20260522.md 最终完整报告 +└── .env API Key 配置(不分享)
+ +

6.2 增量进度报告(每 30 分钟)

+

自动生成于 reports/{game}/latest_progress.md,包含:

+ + +

6.3 最终报告(按系统分模块)

+

探索结束后生成,结构示例:

+
## core_loop(核心循环) +- 主循环为:种植鲜花 → 收获 → 完成订单 → 获取金币/经验 +- 鲜花种植需要种子 + 花盆,花盆数量限制同时种植上限 +... + +## resource(资源系统) +- 金币:完成订单获得,用于购买种子和扩展花盆 +- 元宝:付费货币,用于加速和抽奖 +... + +## monetization(商业化) +- 主要付费点:加速道具、稀有种子抽奖、礼包直售 +- 公会竞赛推动竞争消费 +...
+ +

6.4 数据库直查(高级用法)

+

有 SQL 基础的用户可以直接查询数据库获取结构化数据:

+
# 查看各模块规则数量 +sqlite3 games/my_garden/db/mechanics.db \ + "SELECT module, COUNT(*) FROM rules GROUP BY module ORDER BY COUNT(*) DESC" + +# 导出所有高置信度规则 +sqlite3 games/my_garden/db/mechanics.db \ + "SELECT module, rule_text FROM rules WHERE confidence >= 0.8 ORDER BY module"
+
+ + +
+

七、支持的模型与成本估算

+

工具的分析阶段支持多种视觉 AI 模型,可按需在成本和精度之间取舍。

+ +

7.1 成本模型

+
+
成本分离设计
+ 探索阶段完全在本地运行(OpenCV + 感知哈希),成本为零。只有分析阶段(AI 模型看图提取规则)产生费用。分析频率可配置:降低频率 = 降低成本。 +
+ +

7.2 24 小时运行成本估算

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
模型分析频率24h 估算张数24h 估算成本精度评级
通义千问-VL每 30min~200 张约 0.6 元够用
字节豆包 Vision每 30min~200 张约 0.4 元够用
智谱 GLM-4V每 30min~200 张约 1.0 元够用
Claude Sonnet每 30min~200 张约 4.0 元高精度
+
+ +
+
推荐策略
+ 日常深拆用通义千问(成本最低,精度满足规则提取)。需要精细分析商业化结构或复杂系统时,对特定截图切换 Claude 做二次分析。 +
+
+ + +
+

八、迭代路线图

+

工具的版本演进历程,全部功能已交付。

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
版本能力业务价值状态
MVP自主探索 + 规则提取 + 增量报告单游戏自动深拆已完成
v1.1多游戏对比报告横向对比 3-5 款参照游戏,支撑项目选型已完成
v1.2数值事实提取提取具体数值(定价/时间/消耗量),不止文字描述已完成
v1.3定时重跑 + 活动追踪跟踪竞品运营节奏:限时活动、礼包更替、版本更新已完成
v1.4浏览器模式 + 市场数据采集补充七麦/SensorTower 数据,形成完整视角已完成
v1.5决策报告模板自动生成面向管理层的对比+推荐格式报告已完成
v1.6资源流转建模 + 探索策略优化经济系统拓扑自动推断 + 界面覆盖率提升已完成
v1.7探索智能增强(8 项)模拟真实用户全部交互行为,消除覆盖盲区已完成
+
+ +

8.1 各版本核心交付

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
版本关键命令/能力
MVPexplore + report + doctor + init — 单游戏自动深拆闭环
v1.1compare — 跨游戏规则对齐 + 差异标注 + HTML 对比矩阵
v1.2facts 表 — 结构化数值事实提取(定价/时间/消耗量)
v1.3timeline — 定时重跑 + 活动上下线检测 + 变化时间线
v1.4market + BrowserDriver — 浏览器模式探索 + 市场数据页采集
v1.5decision-report — 多游戏综合分析 + 面向管理层的决策报告
v1.6resource_flows 表 + Tab 扫描 + 滚动探索 — 资源拓扑 + 覆盖率提升
v1.7长按 / 弹窗关闭 / 边缘抽屉 / 悬停 / 加载等待 / 暗色适配 / 自适应滚动 / Cookie 处理
+
+
+ + +
+

九、常见问题

+

使用中可能遇到的问题和解决方式。

+ +
+
Q: ADB 连接失败怎么办?
+ 确认模拟器已启动且开启 ADB 调试。在终端运行 adb connect 127.0.0.1:16384,然后运行 game-analyst doctor 查看状态。MuMu 12 默认端口为 16384,如有多个模拟器实例端口会递增。 +
+ +
+
Q: 探索一直在同一个界面打转?
+ v1.7 起工具会自动检测并关闭弹窗(签到、活动、Cookie 同意等)。若仍出现打转,可能是非标准弹窗。检查日志 games/{game}/logs/ 中的回退记录,或手动关闭后探索会自动继续。 +
+ +
+
Q: 分析结果中 "other" 分类太多怎么办?
+ 这通常意味着模型对该游戏界面的理解不够精确。可以尝试:1) 切换到更强的模型(如 Claude);2) 让工具运行更长时间积累更多界面,后续分析会利用上下文自动修正。 +
+ +
+
Q: 如何同时分析多款游戏?
+ 开多个模拟器实例,每个实例打开不同游戏,分别启动: +
+
game-analyst explore --game game_a --device 127.0.0.1:16384 +game-analyst explore --game game_b --device 127.0.0.1:16416 # 第二个实例端口
+ +
+
Q: 如何把报告分享给不装工具的同事?
+ 使用 game-analyst report --game my_garden --format html --standalone 生成单文件 HTML,用浏览器直接打开,无需任何安装。可以通过飞书/微信直接发送文件。 +
+ +
+
Q: 运行中电脑休眠或网络断了怎么办?
+ 工具具备断线恢复机制:ADB 断连后会自动重试连接;API 调用失败会重试后跳过。已探索的数据不会丢失,重新启动后会从中断点继续。 +
+
+ + +
+

十、适用场景与边界

+

工具擅长什么,不擅长什么,使用者需要明确的期望。

+ +

10.1 适合的场景

+
+
+
竞品机制拆解
+
对目标竞品的系统规则、数值、资源结构、商业化节点进行系统性采集
+
+
+
项目选型调研
+
横向对比多款同赛道产品,生成对比矩阵和决策报告
+
+
+
运营活动监控
+
定期重跑检测竞品活动上下线、礼包更替、版本变化
+
+
+
+
+
市场数据采集
+
浏览器模式采集七麦/SensorTower 等数据页面信息
+
+
+
H5/网页游戏分析
+
对浏览器中运行的 H5 游戏或网页应用进行界面探索和结构分析
+
+
+
新手流程评估
+
自动走完新手引导,记录每一步操作和界面变化
+
+
+ +

10.2 不适合的场景

+
+
以下场景超出工具能力范围
+
    +
  • 深层付费体验 — 工具不会付费,无法探索付费墙后的内容
  • +
  • 实时 PvP / 高操作玩法 — 动作游戏/射击游戏的核心体验无法通过静态截图分析
  • +
  • 社交互动系统 — 公会、好友、聊天等需要多账号交互的系统,单设备无法覆盖
  • +
  • 直接生成商业结论 — 工具提取事实和规则,商业判断由分析师完成
  • +
  • 反作弊规避 — 部分游戏可能检测模拟器环境,导致体验受限
  • +
+
+ +

10.3 使用建议

+
+
最佳实践
+
    +
  • 先手动体验 15-30 分钟,了解游戏基本结构,再挂机让工具补充覆盖
  • +
  • 工具产出的规则报告是初稿,需结合截图核实低置信度规则
  • +
  • 对重点分析对象,建议跑 4-8 小时以获得足够覆盖率
  • +
  • 多游戏对比时,各游戏的探索时长应尽量一致,保证数据可比性
  • +
+
+
+ + + + +
+ + diff --git a/output/downloaded-files/html-md/主报告-我的花园世界.html b/output/downloaded-files/html-md/主报告-我的花园世界.html new file mode 100644 index 0000000..ef126fa --- /dev/null +++ b/output/downloaded-files/html-md/主报告-我的花园世界.html @@ -0,0 +1,1438 @@ + + + + + +《我的花园世界》研究主报告 + + + +
内部研究材料 · 仅供学习与立项参考
+
+ +

《我的花园世界》研究主报告(v1.0 内部研究版)

+
+

编制日期:2026-06-01
+信源基础:黄静雯工作日报、资源经济深度研究(HTML/JS包)、产品对比 xlsx(2025-10-28)、老李游戏课35期、联网公开渠道补充
+配套底稿:补充资料-我的花园世界.md(全部事实、数据、来源与置信度标注)
+置信标注:✅多源一致 | ⚠️单源或口径存疑、待核 | ⛏️需游戏内实测复核

+
+
+

摘要

+
+

本报告的主旨(给产品经理/策划):新项目策划的关键,不是从零发明一套系统,而是识别一个已被用户验证、但尚未被充分放大的底座,并明确公司能用什么能力把它放大。《我的花园世界》正是这一路径的成功范式——它的机制几乎都不原创,赢在"系统放大"。

+
+

《我的花园世界》是 2025 年下半年女性向休闲赛道最显著的黑马:2025 年 8 月上线,峰值 DAU 千万级,峰值月流水预估 4-5 亿元。但它的成功并非来自单点机制的原创,而是来自对一个已被验证的休闲种花品类底座的结构性继承与再组合放大,叠加营销破圈、体验升级与商业化放大。("结构性继承"指玩法结构高度相似、对已验证底座的再组合,现有证据不能证明团队/代码/授权层面的直接关系;详见第三章。)

+

本报告的核心判断有三层:

+
    +
  1. +

    它是"腰部结构 → 外部力量放大"的范例。 真正奠定"种花 + 社交 + 公会竞赛 + 资源规划"品类底座的是深圳天苻科技(《鲜花小镇》2018 → 《秘密花园HD》2023)。而把这个底座放大成现象级产品的,是另一家公司——厦门麟贝互娱。底座验证者与放大者是两家不同主体,这正是"腰部产品被外部团队发现并放大"的典型路径。

    +
  2. +
  3. +

    它证明了"非战斗 GVG"可以撑起重度商业化。 本作打破了传统游戏"养成→战力释放→对抗检验"的逻辑,只有养成积累、没有战斗对抗,靠"养成→满足→社交→再养成"的闭环成立。其公会竞赛是低协同、弱对抗、高覆盖、强分层的异步任务型 GVG,并以"社交拉氪"(让玩家因被需要而付费)弱化传统"卡点逼氪"、叠加社交责任型付费(传统逼氪元素仍存在,详见正文 7.3)。

    +
  4. +
  5. +

    它把游戏行为变成了现实社交货币。 "种虚拟花、收真实花束"是本作最强的增长飞轮:玩家晒的不是"游戏好玩",而是"我真的收到花了",天然适合短视频与社交平台传播。但这同一机制也把游戏运营拖入了实物履约与消费者权益领域,已出现真花兑现难、客服响应慢等投诉——增长资产存在反转为信任风险的可能。

    +
  6. +
+

对公司的价值不止于"研究一款爆款",而在于沉淀一套"发现—验证—迁移—放大"的腰部产品研究工作路径,并把其中可迁移的设计资产(非战斗 GVG 三支柱、社交拉氪范式、虚拟行为→现实社交货币的获客钩子、双层错频活动运营)远程迁移到在研及在线项目。

+

给产品经理/策划的五条结论(先记这五句)

+
    +
  1. 不要学"种花题材",要学"已验证底座 + 放大能力"的立项路径——题材会过时,立项方法不会。
  2. +
  3. 不要简单加公会排行榜,要做"异步、低压、人人有贡献"的非战斗 GVG——排行榜只筛出大 R,贡献型组织才留得住轻度玩家。
  4. +
  5. 不要只做资源卡点,要设计"被需要"的社交付费理由——让玩家因在组织/换花网络中有价值而付费,而非只因被卡住。
  6. +
  7. 不要上线后乱堆活动,要先规划长短周期错频运营——活动要有层级与节奏,否则高密度 = 信息过载。
  8. +
  9. 不要把现实奖励当福利,要把履约/客服当产品能力——掉率、兑换、配送、SLA 不前置,增长钩子会反噬为信任风险。
  10. +
+

推荐阅读路径(按角色取用)

+ +
+

制作人决策摘要(一页纸)

+
+

给制作人 / 立项决策者:本页是全报告的决策化提炼,读完即可判断"要不要立项、需要什么、风险在哪、怎么验证"。完整论证见后文,立项打法见第十三章。

+
+

一、能从这个案例推导出哪些新项目方向

+ +

二、公司必须具备的能力(缺一项就别照抄)

+

营销破圈(女频短剧素材 + 代言 / 话题 + 短视频买量产能)|社交系统设计(异步贡献型组织、资源错配、换花 / 互助网络)|重后端商业化(订阅 / 礼包 / 累充 / 稀缺冲榜 / IAA 的分层组合与数值调控)|长期运营产能(每 1-2 月补系统 + 双层错频活动)|(若做实物)履约与客服(供应链、配送、SLA、投诉闭环)。

+

三、会导致"照抄失败"的风险

+

只换皮、不明确原产品"没做透的环节"(复制了天花板)|只加排行榜当 GVG(劝退轻度玩家、塌掉覆盖率)|把实物奖励当福利(履约 / 客服跟不上,增长钩子反噬为信任风险)|活动高密度但无层级(信息过载、材料挤兑)|用社交拉氪替代全部商业化(传统资源压力仍需存在)。详见 12.3 反面清单。

+

四、前三个月最小验证(MVP)该做什么

+ +
+

一、研究背景与方法

+

1.1 为什么研究这款产品

+

《我的花园世界》在一个看似拥挤、天花板不高的女性向休闲种花赛道里跑出了远超同类的量级。与同品类前辈《秘密花园HD》(月收入百万元级)相比,二者共享几乎相同的核心循环(培育→种植→收获→订单→社交),解锁节奏也接近,但商业量级差距达到 50-100 倍。这种"底层框架相近、结果天差地别"的反差,本身就是最值得研究的对象——它把"决定商业高度的到底是什么"这个问题,从玩法清单层面逼到了放大能力层面。

+

1.2 研究路径定位

+

本报告刻意采用一条与"只研究头部爆款"不同的工作路径:腰部产品发现 → 潜力验证 → 机制迁移 → 力量放大。头部产品往往已高度成熟,学习空间大但复刻窗口小;腰部产品更可能暴露"尚未被充分放大的结构性机会"。《我的花园世界》正是这条路径上的一个成功范式,它的研究价值不仅在于理解这一款产品,更在于建立一种可复用的研究方法,迁移应用到公司在研及在线项目。

+

1.3 信源与口径说明

+

本报告综合了五类信源,各有局限,引用时已分别标注: +- 内部研究(工作日报、资源经济研究 HTML/JS 包):分析深度高,但部分数值依赖社区攻略与实测,需以游戏内截图复核。 +- 产品对比数据(xlsx,2025-10-28):三类数据口径各不相同、不可混算(据原表备注 1-4)——消耗为广点通双端消耗(含 iOS、不含头条);流水 ROI为微信端+安卓端口径(不含 iOS、不含头条,付费率同理),因不含 iOS 流水而 ROI 系统性偏低;注册数据含头条(单价 ×2 参考)。故注册口径与流水/消耗口径不一致、注册数与流水不可直接相除;1~5kw 段样本不足、N 日数据不全。 +- 公开渠道(应用商店、厂商官网、版号、媒体报道):可信度高但时间口径分散。 +- 社区 UGC(TapTap、小红书、抖音攻略):反映真实玩家行为,但需交叉验证。 +- 行业分析(老李游戏课):方法论框架,非一手数据。

+
+

二、产品与厂商画像

+

2.1 厂商归属 ✅

+ +

这是本研究最重要的一处认知校正。 工作日报的对比对象是天苻科技及其《秘密花园HD》,容易让人误以为《我的花园世界》是天苻系产品。实际上,奠定品类底座的天苻(深圳)与放大该底座的麟贝互娱(厦门)是两家完全不同的公司。也就是说,"底座验证者"与"放大者"在主体上是分离的——这恰恰强化了"腰部品类机会可以被外部团队发现并放大"的判断,也意味着这类机会对任何有放大能力的公司都是开放的。

+

2.2 上线时间线 ✅/⚠️

+ +

2.3 平台矩阵与渠道表现

+

本作覆盖 TapTap(安卓)、微信小游戏、抖音小游戏、Google Play、Microsoft Store(PC)及海外 iOS。公开口径的渠道表现(均为动态数据,下表为采集时点快照,截至约 2026 年 5-6 月,复核请以各渠道实时页面为准):

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
渠道公开信息来源
TapTap评分 7.8、下载约 30 万、关注约 42 万、版本 1.2.6(2026-05 末)TapTap 商店页
中国 App Store评分 4.1、约 3.8 万评分、开发者厦门麟贝互娱App Store(CN)
Google PlayModo Global 发行、100 万+下载、评分 4.5、显示 #8 创收最高模拟Google Play
美国 App Store开发者 Modo Game、销售商 MODO PTE. LTD.、评分 4.7App Store(US)
+

榜单峰值(不同时点、来源口径不同):国内曾达 iOS 免费榜霸榜约 2 周、iOS 畅销榜前 5、微信与抖音小游戏畅销榜登顶(麟贝官网口径);国庆期间微信小游戏畅销榜第 6、iOS 畅销榜前 20(TapTap/媒体口径);海外曾进入美国 iOS 手游下载榜 Top 4(虎嗅/搜狐报道)。需注意国内与海外并非完全同一发行主体:国内以麟贝为核心,海外 iOS/Google Play 由 Modo 承接发行与客服。

+

2.4 题材与美术定位

+

本作采用仿唐国风、治愈系基调,明确面向女性向人群。相比《秘密花园HD》的 Q 版古风,本作美术更精致、更适合在小红书/抖音做女性向内容传播。题材的"大众化升级"是后续营销破圈能够成立的前提之一。

+
+

三、品类底座溯源:站在谁的肩膀上

+

3.1 天苻科技的产品线迭代

+

真正在"种花经营 + 公会竞赛 + 资源规划"赛道完成早期验证的是深圳天苻科技,其产品线呈现清晰的"保留底座、逐层加层"特征:

+ +

3.2 已被验证的底座结构

+

到《秘密花园HD》时,这个品类的底座已经相当完整:清晰的核心循环、以园艺社为资源枢纽、把水滴做成核心瓶颈资源(社团种植不耗水滴且双倍产出,使"加入组织"从社交装饰变成经营刚需)、深度的社团竞赛、多层每日回流与长线目标,以及"游戏内社团 + 微信群"的双层玩家自治生态。

+

3.3 秘密花园HD 为何系统完整却非爆款

+

《秘密花园HD》微信小游戏畅销榜最高约第 40 名,月收入百万元级。它缺的不是底座,而是放大能力:营销维度近乎空白;Q 版古风美术在竞争中显古早;乙女恋爱叙事私密、难做 15 秒短视频钩子;商业化以 IAP 为主但深度不足、缺重度设计。

+

3.4 小结:系统完整 ≠ 商业成功

+

决定商业高度的不是系统清单,而是用户规模 × 付费深度 × 留存长度。系统只是基础设施,杠杆在于能否把基础设施转化为用户规模和付费意愿。这是贯穿全报告的第一性判断。

+

3.5 体验升级:流量承接能力如何形成

+

把"体验升级"单列,是因为它是核心乘法公式里最容易被写成口号、却最关键的一项。若不展开,报告会给人"只靠营销和商业化放大"的印象,弱化产品的承接能力——而正是承接能力决定了营销带来的大盘流量是短期冲高,还是沉淀为留存。

+

本作的体验升级不是"画面更好"一句话,而是把轻度用户最容易流失的几处摩擦同时压低——看不懂、做不动、等太久、没得晒、没人回应。可拆为四个维度(前三项证据较足,第四项为推断、待实测):

+ +

可写入结论的判断:体验升级的价值在于承接营销带来的大盘用户,使"真花/代言/短剧"带来的流量不只是短期冲高,而能沉淀为留存。

+

3.6 方法提炼:如何识别"可被放大"的腰部底座

+

对策划读者而言,本章最可迁移的不是天苻的产品史,而是从中抽象出的四条判断标准:

+
    +
  1. 腰部底座识别标准:核心循环已被用户验证(留存/付费结构成立),但美术、传播、商业化、长期运营至少有一层明显没做透——既证明"可行",又留出"放大空间"。
  2. +
  3. 可放大能力判断标准:自问"我方相比原产品能在哪一层形成代差"——题材包装、买量素材、社交生态、商业化深度、长期运营产能,至少要在一项上有明确优势,否则只是平移。
  4. +
  5. 从竞品拆"已验证结构"的方法:拆解时把"玩法清单"与"已验证结构"分开——前者可抄,后者(核心循环 × 资源枢纽 × 组织绑定 × 留存层级)才是真正的底座资产。
  6. +
  7. "有潜力"还是"到天花板"的判断:看它没做透的环节是"能力问题"还是"结构问题"——若只是营销/美术/商业化等能力短板(如《秘密花园HD》),则有放大空间;若是核心循环或需求本身见顶,则放大也无效。
  8. +
+
+

📌 策划可迁移点

+
    +
  • 可学:先找"已被用户验证、但至少一层(美术/传播/商业化/运营)没做透"的腰部底座,再谈放大。
  • +
  • 前提:能拿到该底座的留存/付费/玩法结构证据,并能判断它"差在哪一层放大能力"。
  • +
  • 误用风险:把"对标爆款"当成"借鉴底座",或直接换皮照抄,忽略原产品没做透的环节。
  • +
+
+
+

四、核心玩法与资源经济

+

4.1 核心循环与多出口消耗

+

本作核心循环为:培育花苗 → 播种(消耗种子+水滴)→ 浇水等待 → 收获鲜花,随后通过多个出口消耗鲜花:居民/顾客订单换金币经验、花艺/插花组合高收益售卖、花贸市场交易、公会竞赛换积分与稀缺花卉、收集图鉴等。

+

4.2 多货币体系

+

水滴、金币、花坊币、元宝、公会币构成多货币体系。其中种植是花材的主产出,订单/花坊/公会竞赛是主要消耗出口。水滴类瓶颈资源延续了品类传统,控制玩家的产出节奏。

+

4.3 订单矩阵与"陷阱期"经济 ⚠️/⛏️

+

订单体系至少包含居民订单、顾客订单、绸缎订单、宫廷特供、团单五类。关键在于团单:26 级解锁,每日完成 50/100 单居民订单后触发两次,限时 30 分钟,单次消耗约为普通订单的 3-5 倍。社区核心攻略据此建议"非任务要求的居民订单不做,26 级后囤花只做团单"。

+

这揭示了本作资源经济的真正核心——不是"种花慢",而是"多出口争夺同一批花材"。团单的大数字收益叠加 30 分钟限时,共同制造收益错觉,迫使玩家从随性种植转向库存规划。这是中期留存与付费转化的关键压力点,也是"陷阱期"的来源:30 级后宫廷特供需求从约 300 花提升到约 400 花,容易形成库存压力。

+

4.4 系统开放节点

+

已知 23 级开放花贸市场(交易回补)、26 级开放团单。公会解锁口径存在冲突:工作日报称"均 15 级解锁组织系统",而本地 JS 包称本作为"主线 115 关解锁公会"。二者需以游戏内截图统一口径 ⛏️。

+

4.5 养成系统群 ⚠️/⛏️

+

本作在基础经营之外陆续叠加了宠物系统、花境共生、花灵系统、工坊系统等养成模块。其中花灵系统于 2025 年 11 月(v1.1.2)加入,但其具体机制、收益结构、是否含抽卡/派遣,目前公开信息仍缺,列为待实测缺口。

+

4.6 玩家生命周期与资源压力换挡 ⚠️

+

把分散在资源经济、活动、商业化、社交各章的内容串成一条用户路径,能更直观地说明留存逻辑:本作的留存不是单靠"种花好玩",而是玩家目标不断换挡——先追求经营效率,再追求组织身份,最后追求展示资产与社交关系。下表为基于现有机制的整合推断(非逐项实测,故标 ⚠️):

+ +
+ + + + + + + + + + 新手期看懂种花·首次回报首充 / 免广告 + + 中期经营库存与订单效率VIP / 成长基金 + + 组织加入公会归属周礼包 / 活动花 + + 活动循环四大五小目标礼包 / 抽奖 / 累充 + + 长线展示花园资产·社交圈装扮 / 限定 / 订阅 + 留存不靠"种花好玩",而靠玩家目标不断换挡:效率 → 身份 → 展示 + +
图 2 玩家生命周期换挡:目标逐级抬升,付费点随之迁移
+
+ + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
阶段玩家目标系统推力压力来源可能付费点
新手期看懂种花、完成订单、获得首次回报剧情、订单、广告双倍、真花宣传等待、资源不够、入口偏多首充/小礼包/免广告
中期经营期扩大库存、提升订单效率团单、宫廷特供、花贸市场、花坊多出口争夺同一批花材VIP、广告特权、成长基金
组织加入期加入公会并获得归属公会竞赛、分享、社群招新日贡、任务纪律、怕拖累周礼包、活动花、竞赛花源
活动循环期在四大五小活动中持续获得目标2 周+3-4 天双层轮换活动重叠、材料吃库存、限时奖励活动礼包、抽奖、累充
长线展示期展示花园、维持社交圈拍照诉求、好友扩容、稀有花、真花晒单内容疲劳、客服响应、组织压力装扮、限定花、订阅续费
+

这条换挡路径也是后续"商业化用户分层"(第七章)和"组织侧成本"(第五章)的底层依据。

+
+

📌 策划可迁移点

+
    +
  • 可学:让核心资源面对多个互相竞争的消耗出口(订单/活动/公会/装扮/交易),用"多出口争夺同一资源"制造规划压力,而非单纯调慢产出。
  • +
  • 前提:资源的产出与消耗能被玩家清晰感知,出口之间存在真实取舍。
  • +
  • 误用风险:把"多出口"做成"纯卡点",过度收紧产出会退化为逼氪、劝退轻度玩家。
  • +
+
+
+

五、组织竞赛系统:非战斗 GVG 的范式(报告重点)

+

5.1 定性

+

本作公会竞赛可定性为低协同、弱对抗、高覆盖、强分层的异步任务型 GVG。它不要求成员同时在线协作,不制造频繁的输赢压力,覆盖面广(普通玩家也能贡献),且通过赛段/分池形成清晰分层。

+ +
+ + + + 可持续非战斗 GVG + + ① 撮合稳定 + 痛点:时间错配 + 异步机制 + 分服 / 跨服 / 滚服 + + ② 互补优度 + 痛点:替代弹性失衡 + 中等替代弹性 + 资源错配换花 + 社交拉氪 + + ③ 竞赛投入 + 痛点:搭便车 / 坐庄 + 概率胜负 + 赛季洗牌 + 奖励私有化 + + 异步任务型公会竞赛:低协同 · 弱对抗 · 高覆盖 · 强分层 + +
图 3 非战斗 GVG 三支柱:撑起"只有养成、没有对抗"也能成立的组织生态
+
+ + +

5.2 设计原理:可持续 GVG 的三大支柱

+

借用老李游戏课的分析框架,可持续 GVG 要破解时间错配、竞争失衡、投入不足三大痛点,对应三大支柱——本作在每一支柱上都有清晰对应:

+

① 撮合稳定。 手游用户在时间、金钱、社交意愿上天然差异,"同时在线、紧密协作"的桌游式假设已不适用,时间错配是刚性约束。撮合分两维:时间撮合靠异步机制(养成、任务)覆盖不同在线时段;空间撮合靠分服/跨服/滚服分隔群体,避免"一家独大、无对手可打"。本作的异步任务型竞赛正是时间撮合的产物。

+

② 互补优度。 关键变量是"替代弹性":替代性太强(玩家可被小号/外挂轻易替换),公平性低、会挤出弱势玩家、削弱社交必要性;互补性太强,则短板决定整体上限、拉低效率、让强者失去动力。理想状态是中等替代弹性,让免费/活跃/新加入玩家都能被纳入系统。本作通过资源错配与资源交换构建玩家间强互补关系,弱化"卡点逼氪"、叠加"社交拉氪"——让玩家因"被需要"而主动付费,既减少挤出效应,又有助于可持续商业闭环。

+

③ 竞赛投入。 在前两者基础上还需提升投入、避免低投入/轮流坐庄/搭便车:用塔洛克冲突函数以概率胜负替代绝对胜负,让弱势方保留翻盘希望;用赛季制频繁洗牌打破"轮流坐庄"的卡特尔式共谋;将奖励私有化、按功勋与个人贡献分配,使收益与付出直接挂钩。需说明:本作的分联赛、分池匹配、弱化榜单、缩小奖励差距、个人收益挂个人贡献等设计,主要来自老李框架与社区二手总结,可用这套思路解释,但具体赛制/匹配规则/奖励参数仍待游戏内实测复核(见附录 D)。

+

5.3 付费优势路径 ⚠️

+

公会竞赛的付费分层体现在花卉积分阶梯上:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
花卉来源单花竞赛积分成本/来源定位
花圃普花21免费种植基础分,人人可做
花圃珍花214880 花坊币兑换零氪冲分主力
周花礼包2328 元付费微氪性价比
周花礼包2568 元付费重氪冲分
精灵花/活动花28限时抽奖/活动顶级冲分
+

由此付费优势路径可概括为:当周付费 → 当周竞赛优势 → 排名奖励 → 公会币/材料 → 下轮更强。从单花积分看(21→28,仅 1.33 倍),存在压缩奖励差距的倾向;但付费方的实际优势还取决于付费花源获取量、活动花产量、礼包限购与竞赛任务结构,是否真正"压缩大 R 垄断空间"仍需结合获取量验证(见附录 D),不能仅凭单花倍率下定论。

+

5.4 与秘密花园HD 的结构性相似与升级

+

本作竞赛在赛段轮换、任务类型、个人积分分档领奖等结构上与《秘密花园HD》的社团竞赛高度相似(属结构性继承/对标复用,现有证据不能证明团队、代码或授权层面的直接关系),但在分池匹配、奖励差距压缩、个人贡献私有化等"健康度"设计上更成熟,更系统地抑制了大 R 垄断与搭便车。

+

5.5 为什么"只有养成、没有对抗"也能成立

+

传统游戏依赖"养成积累→战力释放→对抗检验"的逻辑闭环。本作大胆地砍掉了后两环,只保留"养成→满足",并用异步社交与互惠把个人价值转化为集体贡献。玩家的行为动机也随之从"战胜对手"转变为"弥补缺口"——通过生产、寻找或与他人交换所需物质来推进。这构建了一个低压力的正循环,证明非战斗模型同样能形成完整的 GVG 生态闭环并驱动付费

+

5.6 组织侧成本与减压机制(迁移要点)⚠️

+

GVG 的健康度不仅看积分设计,也看组织运营成本。三类关键角色构成组织:普通玩家(提供基础活跃与稳定任务贡献,价值在覆盖率)、付费玩家(提供稀缺花源与冲榜上限,价值在突破上限)、公会管理者(制定日贡、协调任务、招新、踢人、安抚情绪,价值在组织稳定)。

+

低协同并不等于无压力:任务异步降低了实时配合要求,但贡献可见会形成日贡与排名约束,奖励私有化虽抑制搭便车却让低活跃玩家感到压力。由此衍生的负反馈——怕拖累、怕被踢、任务抢接冲突、大 R 虹吸、强弱公会分化、活动与公会任务叠加疲劳——正是"养老公会/无氪公会"出现的根因,本质是玩家对组织压力的自我分层。

+

迁移启发:非战斗 GVG 可以成立,但必须配套减压机制——赛段分层、贡献分档、奖励差距控制、赛季洗牌、低压公会标签;缺一则容易劝退轻度用户,动摇"覆盖率"这一根基。

+

5.7 策划落地:非战斗 GVG 设计参数表

+

把第五章的理论压成一张可直接填写的设计清单——做非战斗 GVG 时,策划至少要先回答这六个参数("本作答案"列中带 ⛏️ 者为框架推断、待游戏内实测复核):

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
参数策划要回答的问题本作的答案(可参照)
贡献单位玩家贡献的是花、订单、积分、体力还是道具?以"花卉换竞赛积分"为贡献单位
参与频率每日、每周、活动期还是赛季?周为单位的竞赛 + 日常贡献
协作方式实时协作还是异步累积?异步累积,不要求同时在线
分层方式按等级、活跃、公会段位还是服务器?分联赛/分池/赛段 ⛏️
付费优势买效率、买稀缺资源,还是买排名?买稀缺花源/效率,单花倍率压缩、不直接买名次
减压机制低压公会、贡献分档、奖励差距、赛季重置怎么做?贡献分档、奖励差距控制、低压/养老公会标签
+
+

📌 策划可迁移点

+
    +
  • 可学:异步贡献型组织目标——人人可贡献、付费拉高上限但不碾压、个人奖励挂个人贡献。
  • +
  • 前提:日常循环能稳定产出可量化的"贡献单位"(花/订单/积分)。
  • +
  • 误用风险:只加排行榜会把组织变成大 R 秀场,劝退轻度用户、动摇覆盖率这一根基。
  • +
+
+
+

六、限时活动系统:双层错频运营骨架

+

6.1 9 活动体系

+

截至 2026 年 5 月,本作共有 9 个常驻限时活动,分两层轮换:四大活动周期约 2 周、任务量大、奖励丰厚,驱动长期留存;五小活动周期 3-4 天、玩法轻松,提供多样性、防止单一玩法疲劳。两层独立轮换、互相补充,构成活动系统骨架。其核心优势在于频率错位:2 周与 3-4 天两种周期不完全同步,使玩家几乎每次登录都遇到不同的活动组合,有效降低疲劳。

+

6.2 四大活动

+

按门槛与数值目标形成梯度: +- 百花成蜜(最简单):种花收花自动积蜂蜜,"无摩擦参与",利于维持低活跃玩家留存。 +- 花笺集芳(中等):完成随机日常任务(订单/采珍珠),2 元宝刷新提供付费出口,但社区反馈其重复频率偏高引发疲劳。 +- 碎玉成瓶(中等偏上):14 天内卖出 7500 个花艺、分三档兑换(合计 880 元宝),高数值目标驱动玩家活动前"囤货",变相延长有效参与周期。 +- 莳花纪闻(依赖库存):系统随机指定种植,对抗"最优化种植",强制玩家维持多样化花种库存。

+

6.3 五小活动玩法梯度

+

五小活动覆盖 5 个轻玩法形态,呈"由轻到重、付费出口递进"的梯度:争芳斗艳(社交投票,零操作)→ 鱼乐无穷(2048,无体力限制)→ 花漾物语(三消,有体力)/香卉甜糕(合成,有体力)/田园奇趣(合成消消乐,有体力且倍数机制驱动冲榜付费)。这一梯度确保不同投入度的玩家都能找到合适的参与方式。

+

6.4 节日与联动层

+

在双层轮换之上,还有节日活动(春节/元旦等,提供情感共鸣与回流付费)和联动活动(如国色芳华联动、杨紫代言期,约 30 天周期,承担破圈获客)。

+

6.5 玩家反馈

+

正面集中在"循环降焦虑"("原来都是循环的,慢慢玩就好")、低门槛活动好评、休闲小游戏解压、内容丰富、真花惊喜;负面集中在随机任务频率过高、碎玉成瓶肝度大、莳花纪闻缺种子卡进度、三消难度偏高、信息过载(不知优先做哪个)、争芳斗艳轻度强制付费。

+
+

📌 策划可迁移点

+
    +
  • 可学:长短周期双层错频 + 节日/联动层,用周期不同步制造"每次登录都不一样"的新鲜感。
  • +
  • 前提:有持续的活动产能与玩法储备,能稳定供给长短两类活动。
  • +
  • 误用风险:活动都抢同一时间/资源/入口,会造成信息过载与材料挤兑,密度≠体系。
  • +
+
+
+

七、商业化结构:轻题材入口、重后端

+

7.1 系统清单 ✅/⚠️

+

本作商业化是一套混合结构,而非单纯卖礼包:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
系统类型关键信息
花之密令通行证 BP普通版+尊享版,完成任务升级领奖
VIP 特权月卡订阅30 元/30 天;一键六连、经验+25%、储水上限翻倍至 130、VIP 商店 8 折、每日 18 元宝+10 水滴
广告特权免广告订阅12 元/30 天(首开 5 折);免广告+视频双倍金币,多类售花收益翻倍
累充档位累计充值最低 38 元起,解锁限定奖励
成长基金等级基金随等级分阶段领取
IAA 广告广告变现广告加速/额外奖励,为免费玩家提供"时间换资源"路径
+

7.2 内购档位

+

中国区可外部复核的内购档位包括 6/12/18/28/30/60/68 元宝档、3 元/8 元活动礼包、30 元会员月卡;美国区可见 VIP Privileges 自动续费 US$7.49 与多个 Garden Pack 档位。

+

7.3 商业化哲学:弱化卡点逼氪、叠加社交责任型付费

+

把系统清单与第五章的 GVG 分析合起来看,本作商业化的内核是订阅提效 + 活动礼包 + 累充/基金 + 抽奖/打榜 + IAA 广告的混合结构,再叠加一层相对独特的设计倾向:通过资源错配制造"被需要",把部分付费动机从"卡点逼氪"转向"社交互惠"。玩家付费不只是因为被卡住不得不买,更因为在公会与换花网络中"被需要",从而主动付费以维持自己的社交价值与地位——这是本作区别于传统重氪 SLG 的特征之一,也呼应了资源经济层"多出口争夺花材"的设计。

+

需要说明的是,这并非"取消"传统付费压力:争芳斗艳的点赞礼包、限时活动的冲榜、抽奖的不透明等仍带有强制付费感,玩家社区也确有相关负反馈(见 6.5、8.5)。更准确的表述是:本作弱化了纯卡点逼氪的比重,叠加了一层社交责任型付费,而非用后者完全替代前者。

+

7.4 用户分层与付费转化 ⚠️

+

把第七章的系统清单与第四章的资源压力合起来看,可勾勒出一条付费转化链:等待太慢 → 广告特权/VIP;库存不足 → 活动/资源礼包;公会排名压力 → 周花礼包/活动花/抽奖;长线效率焦虑 → 月卡/基金/累充。即本作的商业化不是强行打断流程,而是在"多出口争夺同一资源"的结构中出售效率、确定性与社交责任感

+

对应到用户侧,可拆为六层(基于机制的分析推断,故标 ⚠️):

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
用户层行为特征主要付费/变现设计意义
零氪广告党看广告换资源、慢速推进IAA 广告、双倍奖励维持大盘活跃与社交生态底座
免广告党认可游戏但厌烦重复广告12 元广告特权把广告疲劳转化为低门槛订阅
月卡效率党高频上线、追求低摩擦操作30 元 VIP、每日元宝/水滴提升中长期留存与稳定 ARPPU
活动微氪党被限时目标/装扮/花源打动3/8 元活动礼包、节日/小活动礼包承接节日与小活动转化
公会冲榜党被组织目标与排名压力驱动周花礼包、活动花、抽奖、累充支撑高峰流水与公会竞争强度
展示收藏党重视花园外观、稀有花、真花晒单装扮、限定花、联动礼包把情绪价值转成长期消费理由
+

这套分层让"女性向治愈题材"与"重商业化后端"不直接冲突:低门槛层提供免费/低价路径维持大盘,高压力层主要由活动、公会与稀缺收藏承接付费。

+

7.5 数据印证 ⚠️

+

xlsx(广点通口径,2025-10-28)显示:本作首千万段 30 日 ROI 倍率 0.89,远超同类、接近《永远的蔚蓝星球》;付费次留高达 87%,付费 7 留 70%、30 留 40%,保有率在被调查的 5 款产品中均处高位(次~7 留 >70%、次~30 留 >45%)。需强调三类口径不同:流水 ROI不含 iOS、不含头条,故 ROI 系统性偏低、实际表现应更好;消耗含 iOS、不含头条;注册含头条(单价 ×2),与流水/消耗口径不一致、不可直接相除(详见附录 A 备注)。注册留存偏低(次留 0.1)但付费留存极高,符合"轻度大盘 + 高粘性付费层"的休闲社交特征。

+

7.6 缺口 ⛏️

+

抽奖概率、累充完整档位、活动保底、春节套装成本等关键商业化参数仍需游戏内截图复核。

+
+

📌 策划可迁移点

+
    +
  • 可学:轻题材入口 + 重后端的分层变现(订阅提效 / 活动礼包 / 累充基金 / 稀缺冲榜 / IAA),用分层让"低门槛"与"重付费"不直接冲突。
  • +
  • 前提:大盘足够大、留存够稳——低价层托住免费玩家,稀缺层有人买单。
  • +
  • 误用风险:付费广播、抽奖不透明、强制付费感会伤口碑(见 6.5、8.5);分层缺失则题材与商业化正面冲突。
  • +
+
+
+

八、营销与增长飞轮

+

8.1 核心钩子:虚拟行为 → 现实社交货币

+

本作最强的增长资产是"种虚拟花、收真实花束":游戏内种花行为与现实鲜花奖励连接(代言期掉率翻倍)。玩家晒的不是"游戏好玩",而是"我真的收到花了、花很新鲜",这把一次游戏行为转化为可传播的现实事件,天然适合小红书/抖音 UGC。

+ +
+ + + + + + + + + + + 种虚拟花收真花 + 现实社交货币 + 1触达 + 2激活 + 3留存 + 4分享 + 5回流 + +
图 4 增长飞轮:晒单把履约结果导回内容平台,形成二次触达
+
+ + +

8.2 破圈三件套

+

相比《秘密花园HD》营销维度的近乎空白,本作做对了三件事:①实体奖励(真花);②女频强冲突短剧叙事("抓奸→出走→逆袭",适合 15 秒买量素材,对比乙女恋爱的私密难传播);③杨紫代言(同款花束、专属称号/表情包/限定鲜花)。配合峰值买量,把用户规模从十万级推到千万级 DAU——这是后续一切放大效果的前提。

+

8.3 渠道与私域

+

抖音/小红书 UGC(话题 #玩游戏赢真花 等播放超 27.3 亿次)、微信公众号关注/口令/红包封面/兑换码的私域裂变,构成线上获客网络;线下方面,工作日报称布有"八城鲜花驿站",而公开官方渠道目前可核到的是重庆/苏州/长沙/青岛四城线下活动(二者来源口径不同,八城口径待与官方物料核对)。线上线下共同构成联动获客网络。

+

8.4 增长漏斗:从触达到回流

+

把"种虚拟花收真花"写成一条链路、而非单一营销点,才能看清它的杠杆所在:

+ +

与传统买量素材的区别在于:传统素材卖"游戏好玩",本作素材卖"现实收益 + 情绪价值 + 可晒结果"。这让游戏行为变成现实社交货币,玩家更愿意主动帮游戏完成二次传播——这正是它获客效率的来源。

+

8.5 风险面:增长资产可能反转为信任风险 ✅

+

真花机制同时把游戏拖入实物履约领域。2026-04 已有媒体(西西新闻)报道多名消费者投诉真花承诺难兑现、花束与宣传不符、客服响应慢;消费保、黑猫投诉等平台也可见充值、客服不处理、抽奖不透明、真花兑换门槛等投诉。结论:真花不是普通福利,而是增长飞轮的核心;但一旦掉率、兑换门槛、花束品质、客服 SLA 不清晰,营销资产会反向转化为信任风险。

+

8.6 出海差异化

+

海外(美国 iOS)据报道"未依赖传统买量",而是主打"实体奖励 + 虚拟体验"的组合,借真花差异化切入北美市场,曾进入美国 iOS 下载榜 Top 4。

+

8.7 真花履约治理框架(风险的反面是成功条件)

+

第 8.5 节是风险"事实",本节把它升级为可执行的"治理框架"。当游戏把"真实鲜花"作为增长承诺,它就不再只是数字产品运营,而部分进入了电商履约与消费者权益管理领域。六项治理应在营销放量前前置:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
风险点表现对游戏的影响需前置的治理
掉率不透明玩家不知获得真花概率易被认定虚假宣传概率/门槛/规则可查
兑换门槛不清抽到后仍需额外条件破坏惊喜感兑换流程与限制前置说明
花束品质不一致实物与宣传图不符晒单变投诉素材规格标准、替换规则、质检
配送范围限制部分地区无法送达扩散客服压力配送范围查询、补偿方案
客服响应慢投诉排队、退款慢拉低商店评分与口碑SLA、专属通道、问题分级
抽奖/充值争议机制不透明、充值纠纷伤害付费信任公示规则、日志查询、申诉闭环
+

核心判断:对任何"虚拟行为→现实可晒结果"的获客模式,履约能力与客服 SLA 不是运营的附属,而是增长能否持续的前置条件——这也是第十二章迁移清单中"风险前置"一条的来源。

+
+

📌 策划可迁移点

+
    +
  • 可学:找本品类的"虚拟行为→现实可晒结果"钩子,把游戏行为变成现实社交货币,并补全"触达→激活→留存→分享→回流"漏斗。
  • +
  • 前提:结果真实、可展示、可低成本扩散,且履约能力跟得上(不一定非做实物,可以是图/视频/称号/作品/社交身份)。
  • +
  • 误用风险:实物履约失败会反噬信任;只有钩子没有回流闭环,传播会一次性透支。
  • +
+
+
+

九、长期运营节奏

+

9.1 三阶段演化 ⚠️/⛏️

+

本作上线后的运营不是"上线即完成",而是在约 10 个月内完成三次升级:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
阶段时间关键变化含义
基础期2025.4-8核心种花-收花-售卖、花坊、居民订单、换装、宫廷特供、珍珠采集、材料商店先搭完整经营骨架
扩展期2025.9-12小游戏端上线、宠物、花境共生、花灵、花贸市场每 1-2 月补一个核心系统,延缓疲劳
体系化期2026.1-5工坊、春节活动、国色芳华联动、杨紫代言、迷雾花圃、9 活动轮换成型从"内容堆叠"转向"体系化运营"
+

这条节奏(基础系统完整化 → 社交/交易/养成扩展 → 活动矩阵体系化)比单点玩法对比更能解释为什么它能从 2025 年国庆的传播爆发延续到 2026 年春节档。

+

9.2 玩家需求迁移

+

社区呼声显示,玩家需求已从"基础功能"转向更高层:拍照/展示模式(隐藏图标、滤镜、截图保存)、好友系统扩容(100→500 位、搜索、备注)、商业化体验化(密令绑定免广告/会员特权以降低纯数值付费感)、专属客服通道、新玩法(家园装修大赛、花卉交易行、跨服竞技)。这说明用户希望把"我的花园"作为可展示资产——UGC 展示、拍照分享、好友扩容、客服承接应被视为增长闭环的一部分

+
+

十、玩家生态与社区运营

+

本作(与《秘密花园HD》高度相似地)形成了"游戏内公会 + 微信群"的双层自治结构:群内发布日贡要求、竞赛规则、任务抢接规范;管理手段包括游戏内踢出与微信群移出联动;小红书招新时标注等级/赛段/日贡标准,形成社团间分层竞争;并出现"怕拖累""养老公会""无氪公会"等减压型组织需求(其成因与减压机制见 5.6)。

+

由于两款产品玩家生态高度同构,本作在设计社区运营策略时可基于《秘密花园HD》的玩家行为模式提前预判与准备:哪些组织压力会出现、玩家会用什么方式自发管理、哪些负反馈需要缓冲。这本身就是"已验证底座"带来的另一种信息资产。

+
+

十一、竞争格局与模仿信号

+

11.1 同赛道对照

+

xlsx 中并列的对照产品包括《秘密花园HD》《花札物语》《桃源深处有人家》《永远的蔚蓝星球》,以及作为留存/倍率参照的《极品芝麻官》《潮英雄》。结论是这批产品付费次留与后续保有率普遍较高,说明休闲/社交品类一旦完成付费转化,用户粘性可观。

+

11.2 模仿者出现 ✅

+

2026-05 已有报道指出《The Cozy Florist》在叙事开篇、培育-种植-收获-订单-升级循环、Logo/UI 布局上与本作高度相似,仅美术更偏欧美卡通;但其最高仅到美国 iOS 模拟分类畅销榜第 57 名,未进入美国 iOS 游戏畅销榜 TOP200。

+

11.3 护城河判断

+

模仿者的存在说明本作的结构已被外部视作可迁移模板,但仅复制"种花经营 + 真实花束/情绪叙事"的外观,未必能复制其完整系统——国内微信生态、明星代言、线下履约、公会社群与高密度活动共同构成了真正的壁垒。护城河不在单一机制,而在系统组合与运营密度。 按"可复制程度"分层来看:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
层级可复制程度说明
种花经营循环培育/种植/收获/订单/升级容易被模仿
美术与叙事包装中高可换成欧美卡通、现代花店、治愈田园等表达
商业化系统清单月卡/BP/礼包/基金/抽奖可复制,但数值节奏难调
GVG 组织生态中低需要足够大盘、社群密度、赛段分层与管理文化
真花履约涉及供应链、配送、客服、成本控制与信任维护
微信/抖音/小红书传播生态平台环境、用户结构、扩散机制难原样迁移海外
活动密度与长期运营能力需要版本产能、活动设计、数值控制与社区响应
+

可写入主报告的判断:后来者能复制"花园游戏的外观",但不容易复制"真实履约 + 公会组织 + 高频活动 + 平台传播"的组合能力。

+
+

十二、结论与对公司的启发

+

12.1 乘法结构

+

本作的商业高度来自一个乘法结构:

+
+

品类底座(秘密花园HD 已验证)× 营销破圈(用户规模放大数十倍)× 体验升级(进入门槛↓、留存↑)× 商业化放大(在更大用户规模上叠加重度付费)= 商业高度

+
+ +
+ + + + 品类底座已验证 + × + + 营销破圈规模×数十倍 + × + + 体验升级门槛↓ 留存↑ + × + + 商业化放大重度付费 + = + + 商业高度 + DAU 千万级月流水 4-5 亿 + +
图 1 成功乘法结构:任何一层缺失都会限制最终结果
+
+ + +

任何一层缺失都会限制最终结果。《秘密花园HD》缺的不是底座,而是后面几层放大能力。

+

12.2 五条战略启发

+
    +
  1. 系统完整 ≠ 商业成功:决定商业高度的是用户规模 × 付费深度 × 留存长度,系统只是基础设施。
  2. +
  3. 成功是顺序问题:底座验证 → 营销破圈 → 体验升级 → 商业化放大,每一步依赖前一步成果。
  4. +
  5. 营销破圈杠杆 ≥ 机制创新:两款产品机制差距远小于用户规模差距,"虚拟行为→现实社交货币"的获客杠杆远超产品内系统优化。
  6. +
  7. 叙事的传播属性直接影响获客效率:选择内容方向时要评估"叙事能否产生可传播的外部话题"。
  8. +
  9. 已验证底座降低试错成本:腰部产品的验证结果(既证明可行、也暴露天花板)本身就是后来者可利用的信息资产。
  10. +
+

12.3 反面清单:不要误学什么(错误迁移比不迁移更危险)

+

可迁移点之外,更要划清"不能照抄什么"——对 PM 尤其重要,因为错误迁移比不迁移更危险:

+ +

12.4 可迁移清单:从战略启发到团队执行

+

把"可迁移"落到团队可执行的动作,并标注前提与风险(前提不满足时,照搬反而有害):

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
团队可迁移动作前提条件风险
产品设计非战斗 GVG:异步任务 + 个人贡献 + 分层匹配有稳定日常循环和可量化贡献组织压力过强会劝退轻度用户
数值用"多出口争夺同一资源"制造规划压力资源产消能被玩家清晰感知过度卡点会退化为逼氪
商业化低价订阅提效 + 活动礼包 + 稀缺冲榜资源大盘足够大、活动节奏稳定付费广播、抽奖不透明会伤口碑
运营双层错频活动:长活动给目标、短活动给变化有持续活动产能活动过多造成信息过载
增长寻找"虚拟行为→现实可晒结果"的钩子结果真实、可展示、可低成本扩散履约失败会反噬信任
社区支持公会招新、低压公会、好友扩容、拍照展示玩家有展示资产与社交动机社群管理成本上升
客服实物奖励/充值/抽奖问题做成专属处理链路有清晰规则与后台日志SLA 不稳会放大投诉
数据/研究建立"腰部产品扫描→验证→迁移→放大"机制有外部产品库与早期判断标准只看头部会错过可放大底座
+

提炼为五条原则:①非战斗 GVG 三支柱 + 概率胜负/赛季洗牌/奖励私有化;②社交拉氪(资源错配制造"被需要");③为可展示品类找"虚拟行为→现实社交货币"钩子;④双层错频活动 + 每 1-2 月补系统;⑤凡涉实物/线下履约,掉率/门槛/品质/客服 SLA 必须在放量前设计清楚。

+

12.5 研究工作路径建议

+

战略研究部应建立一套"发现—验证—迁移—放大"的腰部产品扫描机制,能更早识别:哪些腰部产品数据不爆但结构有潜力、哪些代表可放大的细分需求、哪些玩法底盘可迁移到公司已有项目、哪些机制适合用内部研发/运营/美术/发行能力放大。《我的花园世界》正是这条路径上的成功范式。

+

12.6 立项评估问题清单(可直接用于立项会)

+

本报告的最终落点,是把上述方法压成立项方案必须回答的 6 个问题。这 6 问答不清,项目很容易变成"系统很多,但没有放大杠杆":

+
    +
  1. 我们借鉴的是哪个已验证底座,而不是只说"对标"哪个爆款?
  2. +
  3. 这个底座为什么没有被原团队放大?(缺的是哪一层能力)
  4. +
  5. 我们能放大的能力是什么?(题材包装 / 买量素材 / 社交生态 / 商业化深度 / 长期运营产能)
  6. +
  7. 核心资源是否有多个互相竞争的消耗出口
  8. +
  9. 是否能做低压、异步、人人有贡献的组织目标?
  10. +
  11. 玩家有什么结果可以拿到外部平台展示
  12. +
+
+

配套详版见 花园项目对策划的启示.md(按 7 条启示逐条展开,含每条的"新项目可怎么做")。

+
+
+

十三、立项打法:如果公司要基于此立项

+

第十二章解决"能迁移什么",本章解决"真要做,怎么开第一枪"——面向制作人与立项决策,把方法落到品类选择、MVP、指标、能力与止损。

+

13.1 适合 / 不适合迁移的品类

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
适合迁移原因不适合 / 慎重原因
休闲经营、生活模拟、装扮收集有稳定日常循环,可承载社交与展示强竞技 / 强数值对抗与"低压、弱对抗"内核冲突
女性向 / 泛大众治愈题材适配短视频传播与社交晒单硬核小众题材难破圈、UGC 扩散弱
已有可量化贡献单位的玩法能支撑异步贡献型 GVG单机叙事 / 无资源循环缺组织目标的承载体
+

13.2 MVP 要验证什么 + 阶段指标

+

指标阈值不写死,先用附录 A 的同类基准做参照系(付费次留 >70%、次~30 留 >45% 是该品类的健康线),再按自身品类校准:

+
+ + + + + + + + + + + + + + + + + + + + + + + + +
阶段验证目标关键指标
首月核心循环 + 多出口资源 + 可晒钩子是否成立次留、7 留;自然分享率 / UGC 产出量
三月异步组织目标 + 分层商业化是否成立组织参与率、轻度玩家留存、付费转化率、ARPPU
半年长期运营节奏能否扛住疲劳30 留、付费留存、活动疲劳曲线、LTV / CAC 趋势
+

13.3 必备团队能力

+

立项前盘点五类能力,缺口即风险:营销破圈(短剧 / 代言 / 买量)、社交系统设计重后端商业化数值长期运营产能(若做实物)履约与客服。任一缺口需在立项方案里写明"如何补齐或外包",否则对应的放大层不成立。

+

13.4 最大风险与止损点

+ +

13.5 线上项目改造对照表

+

对在线项目 PM——不立新项目,也能借这套结构做针对性改造:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
当前项目问题可借鉴改法对应章节
日常循环疲劳增加多出口资源消耗,制造规划压力第四章
公会活跃弱做异步贡献型组织目标,而非排行榜第五章
付费太硬增加效率 / 身份 / 组织贡献型付费第七章
活动太乱建立长短周期错频活动层级第六章
留存后期弱增加展示、收藏、社交资产与晒单钩子第八、九章
+
+

附录

+

附录 A:产品对比数据表(广点通口径,2025-10-28;首千万段节选)

+

下表为各产品 <1kw 消耗段的 ROI1/14/30 节选;完整数据(ROI90/180/360、1~5kw 分段、付费留存等)见 xlsx 原表与 补充资料-我的花园世界.md

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
游戏消耗段总消耗ROI1ROI14ROI30注册CPA付费成本
我的花园世界<1kw973万0.0360.3420.893.7880
我的花园世界1~5kw1840万0.0230.1361.51339
花札物语<1kw992万0.0230.1610.294.01949
永远的蔚蓝星球<1kw981万0.0240.3110.545.7893
秘密花园HD<1kw997万0.0340.2270.382.8514
桃源深处有人家<1kw318万0.0250.1770.274.3688
极品芝麻官(参照)<1kw998万0.0190.0980.182.92466
潮英雄(参照)<1kw999万0.0590.3340.4610.9762
+

留存(注册次/7/30 留,付费次/7/30 留):我的花园世界 0.1/0.06/0.04,0.87/0.70/0.40。 +口径备注(据 xlsx 原表备注 1-5):消耗为广点通双端消耗(含 iOS、不含头条);流水 ROI为微信端+安卓端口径(不含 iOS、不含头条,付费率同理),因不含 iOS 流水而 ROI 系统性偏低;注册数据含头条(单价 ×2 参考),与流水/消耗口径不一致、注册数与流水不可直接相除;1~5kw 段多个产品消耗不足、N 日数据不全、整体偏低;注册留存可能偏低,付费留存与保有率可参考。《极品芝麻官》《潮英雄》为不同品类的留存/倍率参照项,非同赛道产品。

+

附录 B:9 活动一览

+

四大活动(2 周轮换):百花成蜜(自动积蜂蜜)→ 花笺集芳(随机任务)→ 碎玉成瓶(卖 7500 花艺)→ 莳花纪闻(随机指定种植)。 +五小活动(3-4 天轮换):争芳斗艳(投票)、鱼乐无穷(2048)、花漾物语(三消)、香卉甜糕(合成)、田园奇趣(合成消消乐)。

+

附录 C:商业化档位与系统清单

+

见正文第七章。补充:花漾物语等小游戏内含花漾币/田园币兑换商店与排行榜冲榜付费出口。

+

附录 D:待实测任务清单 ⛏️

+

把缺口任务化,标注目的、采集方式与优先级,便于直接派活:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
任务目的采集方式优先级
新手前 30 分钟录屏验证体验升级与转化触点新号录屏,标注剧情/订单/广告/付费/真花露出P0
公会解锁流程截图解决 15 级 vs 主线 115 关冲突记录等级、主线关卡、公会入口出现时间P0
花贸市场规则截图验证交易是否支撑"社交拉氪"截交易范围、价格、限制、税费/手续费P1
花灵系统截图判断是否含抽卡/派遣/收益加成截入口、获取方式、养成材料、收益说明P1
抽奖与活动保底截图补商业化参数缺口截概率、保底、累充全档、礼包价格P1
真花兑换全流程验证履约风险与治理框架截掉落、兑换、地址、配送规则、客服入口P1
公会招新样本验证组织生态小红书/微信群样本:等级、赛段、日贡、请假、踢人规则P2
海外版商店与榜单验证出海判断App Store/Google Play/数据平台截图P2
+

附录 E:论点—证据—置信度—缺口表

+

为避免强推断与弱事实混淆,列出主要论点的证据强度:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
论点主要证据置信度缺口
厂商为厦门麟贝互娱,非天苻官网、TapTap、App Store、版号/充值站股权/分成无需作为主线
底座与天苻系已验证结构高度相似(结构性继承)工作日报对《鲜花小镇》《秘密花园HD》拆解中高仅结构相似,无团队/代码/授权直接关系证据;需更多同屏/流程对比截图
峰值 DAU 千万、峰值月流水 4-5 亿工作日报口径需第三方数据平台复核
9 活动双层轮换本地 HTML/JS 专题报告需当前版本验证是否变动
商业化系统完整、混合变现本地 JS、App Store 内购档位中高抽奖概率、累充全档、保底仍缺
团单/积分阶梯等资源经济细节本地 JS 包、社区攻略需游戏内实测复核
真花履约存在投诉风险西西新闻、投诉平台、社区反馈中高需投诉样本量与解决率
海外表现有增长Google Play、美国 App Store、媒体报道需 Sensor Tower/Data.ai 收入榜单
+

附录 F:信源清单与置信度

+

补充资料-我的花园世界.md 第二、三、七节及来源链接。

+
+ + diff --git a/output/downloaded-files/html-md/取败之道——关于幸存者偏差、筹码管理与生长逻辑的深度反思.md b/output/downloaded-files/html-md/取败之道——关于幸存者偏差、筹码管理与生长逻辑的深度反思.md new file mode 100644 index 0000000..8433f16 --- /dev/null +++ b/output/downloaded-files/html-md/取败之道——关于幸存者偏差、筹码管理与生长逻辑的深度反思.md @@ -0,0 +1,227 @@ +# 取败之道:关于幸存者偏差、筹码管理与生长逻辑的深度反思 + +> 负数学期望的策略,因为参与者数量多形成的极端幸存者偏差,往往是引领我们犯错的坏榜样。这是聪明人往往难以绕过的重大陷阱。 + +--- + +## 一、极端值不是你的路标 + +我做了十几年游戏。早期做的是一个不起眼的品类,团队十来个人,产品朴素,用户宽容,收入稳定。那时候我每天想的只有一件事——怎么活过这个月。没有什么长远规划,就是活着。 + +但你打开任何一个行业媒体,看到的永远是王者荣耀、原神、逆水寒。这些产品日活千万、流水过亿,常年霸占你的视线。而身边那些闷声赚钱的中小公司,从来不会出现在报道里。 + +这就是幸存者偏差最残酷的地方:**你看到的永远是极端值,而极端值恰恰是最不可复制的。** + +一个赛道有一千家公司参与,最终跑出来一两家,媒体反复报道这一两家。作为旁观者,你看到的是"预见+坚持=神话",你看不到的是另外九百九十八家的尸体。你会不自觉地认为那条路是可走的,因为有人走通了。但你忽略了一个数学事实:如果这条路的数学期望是负的,那一两个人走通了恰恰证明的是随机性,而不是方法论。 + +我就是这样被带偏的。 + +--- + +## 二、我是怎样走上取败之道的 + +早期那个不起眼的品类,我做了好几年,利润稳定,团队精干,成本极低。这是一条正期望的道路——虽然单次回报不大,但它是真实的、可持续的。 + +但我不满足。 + +我看到那些头部大作的辉煌,觉得自己也应该做一款真正伟大的产品。我给自己设定了一个目标:做一款能长线运营、持续增长、比肩头部的"长青大作"。 + +于是我把前面赚到的利润拿出来,组建了更大的团队,进入了一个竞争更激烈、不确定性更高的赛道。产品上线后,确实有过一段短暂的爆发——数据在三个月内冲到了一个很好看的位置。 + +然后呢?开始往下走。 + +如果这时候我是一个没钱的创业者,我会立刻收手。但我不是。我有钱、有团队、有"我能做到"的信念。于是我做了所有聪明人都会做的事——加注。 + +加人、加内容、加商业化设计。目标很清晰:只要把曲线拉回去,前面的投入全部能收回来。这个逻辑听起来无比合理。但现实是:曲线继续往下走,成本线继续往上走。两条线之间的剪刀差,就是我每个月在流血的金额。 + +这样的状态持续了两年多。 + +--- + +## 三、All in 的心理学 + +回头看,问题不在于我做了一个错误的判断。**问题在于我无法止损。** + +为什么无法止损?因为几个心理机制同时在起作用: + +**沉没成本谬误。** 已经投入了这么多,如果现在放弃,前面的就全白费了。"再坚持一下"永远比"认赔出局"更容易被接受。 + +**能力幻觉。** 我觉得自己足够聪明、足够有能力,一定能找到破局的方法。这种信念本身就是聪明人最大的陷阱——正因为过去确实成功过,所以更加相信自己能把负期望翻正。 + +**窗口期焦虑。** 我觉得机会稍纵即逝,如果现在不全力以赴,以后就再也没有这个机会了。这个叙事极具说服力,但它有一个致命的隐含前提:你能在事前准确识别哪个是真窗口。现实是,你看到的每一个"窗口"都觉得是真的——否则你根本不会注意到它。但事后回头看,大部分窗口都是幻觉。 + +**资源的止痛效应。** 有钱就意味着容错空间大,容错空间大就意味着反馈信号弱。以前一个错误三天就会疼,现在一个错误可以被预算、汇报、信念、组织惯性包裹起来,半年甚至一年后才显形。等到痛感传来,往往已经不只是产品问题,而是团队结构、成本结构和心理结构一起僵化了。 + +**钱是组织的止痛药。** 止痛药让你在骨折的时候还能跑。跑着跑着骨头就碎了。 + +--- + +## 四、取败之道的数学结构 + +让我把这个教训还原成数学语言: + +**负期望博弈 + 极端幸存者偏差 + 没有筹码管理 = 取败之道。** + +拆开来看: + +1. **负期望博弈:** 在一个参与者众多、成功率极低的赛道中,大多数参与者的平均回报是负的。少数人获得巨大成功,但这少数人的成功不能改变整体期望为负的事实。 + +2. **幸存者偏差的误导:** 我们只看到幸存者的故事,并从中提取"因果关系"——他做对了什么,他坚持了什么,他的战略是什么。但这些事后叙事在统计上毫无意义,因为我们没有看到另外几百家做了同样事情却失败了的公司。 + +3. **没有筹码管理:** 把大量资源押在单一结果上,没有留足后手,没有设置止损线,在信号已经明确告诉你"不行"之后仍然继续加注。 + +4. **All in 的诱惑:** 聪明人尤其容易 all in,因为他有能力说服自己"这次不一样"。能力感本身就是 all in 的心理燃料。 + +与之相对的是: + +**微弱正期望 + 筹码管理 + 持续参与 = 取胜之道。** + +你不需要每次都对。你需要的是:每次下注足够小,期望值哪怕微弱但为正,有足够多次参与的机会。大数定律会做剩下的事。 + +--- + +## 五、"挣小钱的心态"为什么有效 + +我回想自己最成功的那段时期,有一个很反直觉的特征:**我没有任何宏大目标。** + +我当时只想着怎么让这个产品多赚一点,怎么让这个活动效果好一点,怎么让这批用户留下来。没有"三年规划",没有"对标头部",没有"长青大作"的愿景。 + +那时候我每天看数据,用户说什么我马上就知道,哪个活动效果好我第二天就能决定加码还是砍掉。不需要开会讨论,不需要等汇报。反馈回路极短——想法从产生到验证,可能只需要几个小时。 + +这种状态为什么有效?因为它天然满足了正期望博弈的所有条件: + +- **成本极低:** 试错不致命,每一次尝试的代价几乎可以忽略。 +- **反馈极快:** 不需要等三个月才知道对不对,当天就能看到数据。 +- **参与次数极多:** 一年可以做几十上百次小实验,大数定律有足够的样本量。 +- **自动止损:** 因为每次投入都很小,"放弃"这个决定几乎没有心理成本。 +- **意外收获的空间:** 大量快速试错中,偶尔会撞到意料之外的东西,那些意外往往比规划更有价值。 + +后来我把这个状态叫做"生长"。**不是设计出来的成功,而是在大量接触现实中长出来的成功。** + +--- + +## 六、为什么有钱之后反而做不好 + +这是最反直觉的教训:**资源充裕本身就是生长逻辑的天敌。** + +有钱意味着什么?意味着你可以承受更大的错误而不立刻感到疼痛。意味着你可以组建更大的团队——而更大的团队意味着更多的中间层、更长的信息链路、更慢的反馈速度。意味着你有能力"做大事"——而做大事意味着单次投入高、周期长、试错次数少。 + +一切条件都在推你从正期望博弈滑向负期望博弈,而你浑然不觉,因为你觉得你在"升级"。 + +我做养成的时候,抱着挣小钱的心态,结果越来越大。后来抱着挣大钱的心态,就越来越小。 + +这不是偶然。这是结构性必然。 + +挣小钱的心态 = 低成本、高频试错、对反馈极度敏感、不敢浪费任何一块钱。 + +挣大钱的心态 = 大投入、长周期、对负面信号容忍度高、相信只要坚持就能翻盘。 + +前者恰好是正期望博弈的最佳姿态,后者恰好是负期望博弈的典型特征。 + +--- + +## 七、规划逻辑的陷阱 + +在反思了上述教训之后,我犯了一个新的错误:试图把教训变成方法论。 + +我从失败中"总结"出了一套战略框架,然后试图用这套框架去指导未来的决策。这听起来像是聪明人该做的事——从失败中学习嘛。 + +但问题是:**你不能用规划逻辑来实现生长逻辑。这句话本身就是矛盾的。** + +生长的本质是什么?是在不确定性中通过高频试错逐渐长出方向。它不依赖于事先知道答案,而依赖于每一步都直接接触现实、直接接收反馈、直接承受后果。 + +规划的本质是什么?是假设你已经知道了某些东西——知道方向、知道路径、知道因果关系——然后据此制定行动方案。 + +当你从一次成功中"总结方法论"的时候,你做的事情是:从 N=1 的样本中提取因果关系,然后把它当作普遍适用的规律。这在统计上毫无根据。换项目、换时间窗口、换品类、换用户群体,同样的方法论可能完全失效。 + +更危险的是:一旦你有了一个战略框架,所有人就开始用这个框架来筛选信息。符合框架的信号会被放大汇报,不符合的会被忽略或淡化。**你最终看到的世界是被你自己的战略框架重新塑造过的。** 这是确认偏差最深层的运作方式——它不是你在有意选择性地看信息,而是你的认知框架自动过滤了你接触到的现实。 + +--- + +## 八、假说不是信仰 + +那是不是就不能有任何判断、任何方向感了? + +当然不是。关键是区分"假说"和"信仰"。 + +假说是好东西。它给你方向感,给你观察的焦点,让你在面对混沌信息的时候知道优先看哪里。问题从来不是"有没有假说",而是**假说有没有保持它"假说"的身份。** + +一旦它变成了信仰——变成了不容修正的前提、变成了组织的口号、变成了所有人围绕它来寻找证据的东西——它就不再是指引,而是遮蔽。 + +正确的姿态是: + +- 假说可以有,但不 all in。 +- 用最小成本、最短周期去验证和修正。 +- 不管数据好坏,都要刻意去看假说**没有预测到的部分**。 +- 如果经过三五次低成本实验仍然成立,它就从猜想变成了被踩出来的路。 +- 如果被反复否定,就果断放下,不要因为"已经投入了这么多思考"而执着。 + +**假说是手电筒,不是隧道。手电筒照亮一个方向,但你眼角余光看到的东西可能比正前方更重要。** + +--- + +## 九、非对称博弈的正确打法 + +如果把创业简化为一场概率博弈,那么最重要的不是提高单次胜率——因为在高度不确定的环境中,单次胜率永远是低的。最重要的是: + +**设计一种下注方式,让你赢的时候赢得够多、输的时候输得够少,而且永远不会被淘汰出局。** + +这就是非对称博弈。 + +具体来说: + +1. **保护下限。** 永远不把全部筹码押在一把上。错过一个机会少赚一笔,但你还在牌桌上;all in 一个假机会,可能直接出局。这两个后果的量级完全不对等。 + +2. **多次参与。** 如果命中率是 8%,那么你需要至少打十几把才有足够高的概率中一次。前提是每次打的成本要低、速度要快。如果每次打一把要半年,你一辈子打不了几把。如果每次只要一个月,一年就能打十二把。 + +3. **不追求最优解。** 最优解往往意味着集中全部资源、押注单一路径。但在不确定环境中,"最优"本身是无法事先确定的。追求最优解的人容易陷入"窗口期焦虑"——觉得机会稍纵即逝,所以必须立刻全力以赴。事实上,真正有生命力的机会不依赖窗口期,它是一个持续存在的结构性趋势。 + +4. **让每次试错都产生学习。** 输了不是白输。每一次接触现实都在积累经验和直觉。试得越多、反馈越密集,你的命中率本身也在提升——不是因为你变聪明了,而是因为你在大量实践中训练了对信号的识别能力。 + +--- + +## 十、生长逻辑的组织含义 + +以上说的主要是决策者个人的思维方式。但在一个有几十上百人的组织里,问题还有另一个维度:**组织结构本身会吞噬生长的可能性。** + +一个正在赚钱的业务会自然地积累人员、流程、层级。这些东西一旦形成,就有了自身的惯性——每个人都在维护自己的岗位,每个流程都在证明自己的必要性。这不是因为人有恶意,而是因为激励结构天然如此。 + +当市场告诉你"应该收缩"的时候,组织的阻力会让你慢半拍。当 AI 让某些岗位的产出效率提高五倍的时候,这五倍的效率很可能被组织内部的结构性损耗吸收掉,最终不反映在利润上。 + +我见到一个数据:AI 在企业中的渗透率很高,普遍提效在五到十倍,但企业的绩效增长不到 5%。这说明效率的提升被组织内部的管理和结构性矛盾给消化掉了。 + +这不是 AI 不好用。这是组织的刚性把所有增量都吃掉了。 + +--- + +## 十一、怎样在有资源之后仍然保持生长 + +这是最难的问题。我没有完美答案,但有几个方向: + +**第一,不是把整个组织缩小,而是在现有组织旁边长出极小的试验体。** 不改造老系统,让新系统在边缘生长。如果跑出来了,老系统的人自然会靠拢;如果跑不出来,也没伤害现有运转。关键是这个试验体必须直接暴露在市场里,有真实的用户、真实的收入、真实的痛感。 + +**第二,让关键决策者重新回到一线。** 不是通过仪表盘看世界,而是直接接触用户、直接感受产品、直接承受后果。AI 的价值不在于辅助决策,而在于释放决策者的注意力,让他从事务性工作中解放出来,有更多时间去直接接触现实。 + +**第三,用结构来保证纪律,不靠意志力。** 成本线不能漂移,这是硬约束,不因任何乐观信号松动。不是因为某个战略理论告诉你应该这样,而是朴素的财务常识:在信号不明确的时候,保护下限永远优先于追求上限。 + +**第四,抵制"从成功中提炼方法论"的冲动。** 方法论一旦固化,就变成下一轮规划逻辑的种子。保持假说的身份——可以有方向感,但不能变成信仰。 + +--- + +## 十二、结语 + +写这篇文章的过程中,我意识到一件事:这些道理我在成功的时候全都"知道"。我在早期做对的时候,并不是因为想通了这些才做对的——我只是恰好处在一个逼着我做对的环境里。小团队、没钱、必须活着,这些约束天然地把我推向了正确的策略。 + +后来有了钱、有了团队、有了"做大事"的资格,约束消失了,错误的策略变得可承受了,于是它就悄悄地发生了。 + +所以我对自己最大的警惕是:**不要相信自己"想通了就不会再犯"。** 理解一个道理和践行一个道理之间隔着巨大的鸿沟。真正能防止重蹈覆辙的不是认知,而是结构——让约束重新回到环境中,让痛感重新变得即时,让反馈回路重新缩短到你无法忽视。 + +最后回到开头那句话: + +> 微弱正期望下通过筹码管理进行持续博弈,才是行动的常态。极端爆发属于随机误差,只可遇不可求。 + +这不是一句鸡汤。这是我花了几个亿买来的教训。 + +--- + +*2026年5月* diff --git a/output/downloaded-files/html-md/战略群文档完整总结.md b/output/downloaded-files/html-md/战略群文档完整总结.md new file mode 100644 index 0000000..5187d44 --- /dev/null +++ b/output/downloaded-files/html-md/战略群文档完整总结.md @@ -0,0 +1,171 @@ +# dc战略问题研究院 - HTML/MD 文档完整总结 + +> 整理时间:2026-06-02 | 来源:钉钉群 dc战略问题研究院 群内分享的文件附件 + +--- + +## 文件清单(共 9 个文件) + +| # | 文件名 | 作者 | 日期 | 大小 | 类型 | +|---|--------|------|------|------|------| +| 1 | 主报告-我的花园世界.html | 李志健 | 2026-06-01 | 90KB | 研究主报告 | +| 2 | 进一步的思考.md | 李志健 | 2026-06-01 | 8.4KB | 立项启发 | +| 3 | 花园项目对策划的启示.md | 李志健 | 2026-06-01 | 5.4KB | 策划启示 | +| 4 | 花园世界等相关产品25.10.28.xlsx | 李志健 | 2026-06-01 | 452KB | 数据表 | +| 5 | 花园世界产品策略_GOS补充信息.md | 傅明游 | 2026-05-26 | 2.7KB | GOS侧补充 | +| 6 | 2026-05-25_report_my_garden_world_us_project.html | 黄静雯 | 2026-05-26 | 46KB | 美国版策略报告 | +| 7 | game-analyst-agent-manual.html | 黄静雯 | 2026-05-22 | 49KB | 工具说明书 | +| 8 | 2026-05-yunhu-project-selection-strategy-report.html | 黄静雯 | 2026-05-21 | 40KB | 云湖项目选择报告 | +| 9 | 取败之道.md | 李志健 | 2026-05-20 | 15.2KB | 战略反思 | + +--- + +## 一、《我的花园世界》研究主报告(李志健,90KB 核心报告) + +### 核心判断 + +1. **腰部结构到外部力量放大** 的范例:真正奠定品类底座的是深圳天苻科技(鲜花小镇2018/秘密花园HD2023),放大成现象级产品的是厦门麟贝互娱。底座验证者与放大者是两家不同公司。 + +2. **非战斗GVG可撑起重度商业化**:打破传统养成-战力释放-对抗检验逻辑,靠养成-满足-社交-再养成闭环成立。公会竞赛是低协同、弱对抗、高覆盖、强分层的异步任务型GVG。 + +3. **游戏行为变成现实社交货币**:种虚拟花收真实花束是最强增长飞轮,但也把运营拖入实物履约领域,存在信任风险。 + +### 产品数据 +- 峰值DAU千万级,峰值月流水预估4-5亿元 +- 2025年8月上线,iOS免费榜霸榜约2周,畅销榜前5 +- 海外曾进入美国iOS手游下载榜Top 4 +- Google Play 100万+下载,评分4.5 + +### 四层产品结构 +1. 低压经营入口:种花、收花、订单、布置、收集 +2. 横向收集和展示:花灵、限定花、装饰、称号 +3. 公会异步任务型GVG:每周竞赛,有限次数 +4. 极致消耗引擎:日常订单+活动任务+公会竞赛限时任务 + +### 五条战略启发 +1. 不要学种花题材,要学已验证底座+放大能力的立项路径 +2. 不要简单加排行榜,要做异步低压人人有贡献的非战斗GVG +3. 不要只做资源卡点,要设计被需要的社交付费理由 +4. 不要上线后乱堆活动,要先规划长短周期错频运营 +5. 不要把现实奖励当福利,要把履约客服当产品能力 + +--- + +## 二、美国版产品策略报告(黄静雯,46KB) + +### 六面承重墙(复刻不能走形) +1. 双层结构:第一层独立成立,第二层驱动变现 +2. 竞赛是需求放大器:放大图鉴收集需求 +3. 氪金=被需要:高氪跟普通玩家共生不对立 +4. 每周+次数有限:有目标但不绑每天 +5. 资产跟人走:高流动+低损失+竞赛期锁定 +6. 大通服+小池匹配:社交池大+竞争可控 + +### 行业趋势 +- 休闲入口嫁接中重度运营已成出海方向 +- Gossip Harbor 2025年总流水约6.5亿美元 +- 差异化不再是方向选择,而是执行细节 + +--- + +## 三、广州云湖工作室项目选择策略报告(黄静雯,40KB) + +### 背景 +云湖当前约16人,目标2个月开发+第3个月上线测试,面向美国市场。 + +### 推荐排序 +1. **第一优先:欧美化花园/庄园/花店经营养成** - 系统复杂度低、AI美术适配度高 +2. **第一梯队备选:欧美化泛用户历史/家族/宫廷养成** - 商业化确定性更高 +3. **备选:宠物/奇幻生物/轻培育经营** - 底层循环与花园高度同构 + +### 关键判断 +- 公司最成功养成产品的本质是泛用户/女性高占比导入+深养成商业化 +- 延趣等团队已做到3个月换皮上线,轻养成赛道进入门槛正在降低 + +--- + +## 四、game-analyst-agent 工具说明书(黄静雯,49KB) + +通用产品分析自动化工具。六大能力: +1. 自主界面探索(Android模拟器+浏览器双模式) +2. 机制规则+数值提取(AI视觉模型) +3. 多游戏横向对比(HTML对比矩阵) +4. 活动追踪与时间线 +5. 市场数据采集(七麦/SensorTower) +6. 决策报告生成 + +技术特点:探索阶段成本=0,分析阶段24h连续运行<1元。 + +--- + +## 五、GOS补充信息(傅明游,2.7KB) + +- GOS尝试种花类买量素材,点击率和获客成本无明显优势 +- GOS复刻花园世界低压力循环原型,效果好于常规活动 +- GOS将GVE拆分为独立活动,预计7月周年庆上线 +- GOK/VK偏SLG,模型能做到1.5~2倍LTV差异 + +--- + +## 六、花园项目对策划的启示(李志健,5.4KB) + +七条启示: +1. 立项找可放大的腰部底座 +2. 先设计稳定日常循环(核心资源多出口) +3. 非战斗GVG值得重点研究 +4. 设计被需要的付费理由 +5. 增长钩子在策划阶段就考虑 +6. 活动系统早规划节奏 +7. 风险能力也是产品能力 + +立项检查6问: +1. 借鉴的是哪个已验证底座? +2. 底座为什么没被原团队放大? +3. 我们能放大的能力是什么? +4. 核心资源是否有多个消耗出口? +5. 是否能做低压异步的组织目标? +6. 玩家有什么结果可以拿到外部展示? + +--- + +## 七、进一步的思考(李志健,8.4KB) + +五条立项思路: +1. 腰部产品放大型 +2. 非战斗GVG型产品 +3. 可晒成果型产品 +4. 资源错配社交型 +5. 轻题材+重后端 + +核心抽象:找一个已被用户验证但还没被充分放大的底座,用公司的美术、商业化、运营、发行能力系统性放大。 + +--- + +## 八、取败之道(李志健,15KB) + +核心论点:负期望博弈+极端幸存者偏差+没有筹码管理=取败之道 + +对立面:微弱正期望+筹码管理+持续参与=取胜之道 + +关键教训: +- 资源充裕是生长逻辑的天敌 +- 挣小钱的心态=正期望博弈最佳姿态 +- 规划逻辑vs生长逻辑不可混淆 +- 假说是手电筒,不是隧道 + +金句:钱是组织的止痛药。止痛药让你在骨折的时候还能跑。跑着跑着骨头就碎了。 + +--- + +## 群内重要讨论摘要 + +### AI落地的紧迫性(李志健,2026-05-24) +- AI工具端的进步并没有转化为业务结果的最终变化 +- 行业正在快速洗牌,没有明显进步的就是在退步 +- AI军备竞赛跟不上的公司会迅速被淘汰 +- 林峰:强制所有人必须用AI,PM按AI流程重新排任务时间 + +### 研究的根本目的(李志健,2026-05-23) +- 聚焦解决业务部门当前具体问题 +- 追求微小可量化能落地的相对竞争优势 +- 一年内可见的反应在业务财务收益上的价值 diff --git a/output/downloaded-files/html-md/模型报告.html b/output/downloaded-files/html-md/模型报告.html new file mode 100644 index 0000000..d71cdc9 --- /dev/null +++ b/output/downloaded-files/html-md/模型报告.html @@ -0,0 +1,740 @@ + + + + + +手游市场战略研究模型 + + + +
+ + +
+

手游市场战略研究模型 v32

+

基于 Agent-Based Simulation 的开发商与发行商策略演化分析  ·  仿真周期 30–50 年  ·  10,000 家开发商 × 2,000 家发行商

+
+ + +
+
?
研究问题
+

+ 在一个存在学习效应、市场周期、产品类型分化、规模上限、动态分成的手游市场中, + 开发商应该选择什么产品策略才能在长达 30 年的市场竞争中存活,并为进入者创造最大的期望收益? +

+
+ 核心指标:期望年化收益 = 存活率 × 幸存者年化收益。 + 这是一个随机进入市场的参与者所能期望的真实年化回报——同时惩罚高淘汰率策略和低收益策略。 +
+
+ + +
+
🏢
市场结构
+ +
+
+
开发商
+
10,000 家
+
能力 AP ~ N(50, 20),截断至 [0, 100]
+ 稳定性 SD ~ N(20, 10),截断至 [1, 50]
+ 初始资金 ~ N(5C, 2.5C),最低 0.1C
+ 每年最多开发 1 款产品(固定,不允许并行)
+
+
+
发行商
+
2,000 家
+
能力加成 pub_ability ~ N(3, 1),截断至 [1, 5]
+ 初始资金 ~ N(5C, 2.5C),最低 0.1C
+ 并行接单数由资金隐式决定(无硬上限)
+
+
+
市场进入与退出
+
动态补充
+
每年破产清算后补充缺口 × 50%,使总数向初始规模均值回归。 + 破产后永久退出,进行中的项目继续完成但收益归零。
+
+
+
破产门槛
+
资金不足
+
+ 开发商:无活跃项目 且 资金 < 下一款产品的开发商承担成本
+ 发行商:无活跃项目 且 资金 < 0.5C
+
+
+
+ + +
+
💰
财务模型
+ +

项目周期资金流

+ + + + + + + + + + + + + + + + + + + +
时点开发商发行商
启动时扣除 cost × 70%扣除 cost × 30%
成功完成(质量 P ≥ Q=80)收回 cost×70% + dev_split × profit收回 cost×30% + (1−dev_split) × profit
失败完成(P < Q)损失 cost×70%(不退还)损失 cost×30%(不退还)
+ +
+ + 利润公式:profit = (P − 80) × 0.2 × rev_mult, + 其中 P = clip(N(eff_AP, eff_SD) + pub_ability, 0, 100) + +
+ +

产品类型

+ + + + + + + + + + + + + + + + + + + +
类型成本AP 倍数SD 倍数特点
普通× 1 C× 1.0× 1.0基准类型
高投入× 2 C× 1.2× 0.7高成本、高质量均值、低方差
低投入× 0.5 C× 0.8× 1.5低成本、低质量均值、高方差(高风险)
+
+ + +
+
四大核心机制
+ +
+
+

① 学习效应 + 遗忘

+

同类型连续开发每年 AP 乘数 +1%;切换类型则乘数重置为 1.0(转型惩罚)。 + 每 5 年所有存活开发商的学习增量减半,防止无限复利,均衡稳态约 1.05–1.06×。

+
multiplier ← 1.0 + (multiplier − 1.0) × 0.5 (每5年)
+
+
+

② 市场红利(双层)

+

集中度红利:占比越低的类型 bonus 越高(上限 2.0×,下限 0.5×),奖励逆势进入。
+ 市场趋势冲击:每 5 年随机切换趋势类型,趋势类型额外 ×1.5。两信号叠乘,方向可能相反。

+
rev_mult = bonus[type] × (1.5 if trend else 1.0)
+
+
+

③ 市场规模上限

+

前 15 年为自由增长期,锁定历史最高年总利润为上限。 + 第 16 年起,若当年利润总和超出上限,等比压缩所有成功项目的利润部分(成本回款不受影响)。

+
scale = market_cap / total_revenue (超出时)
+
+
+

④ 动态分成

+

每年根据当前活跃项目的主流产品类型调整利润分成:高投入产品主流时开发商获6:4优势,低投入主流时发行商获6:4优势,均衡时5:5。

+
+ 高投入主流 → dev : pub = 6 : 4
+ 普通主流  → dev : pub = 5 : 5
+ 低投入主流 → dev : pub = 4 : 6 +
+
+
+ +
+ 机制互动关键点: + 专注高投入策略触发 6:4 分成 → 开发商利润增多 → 市场总利润更快超出上限 → 规模上限更早、更猛地压缩后期收益。 + 两个机制在高投入策略下形成"给了又收回"的抵消效应。 +
+
+ + +
+
🎯
开发商策略选项
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
策略决策频率逻辑学习乘数
专注普通不切换始终开发普通产品持续积累
专注高投入不切换始终开发高投入产品,享受6:4分成持续积累
专注低投入不切换低成本高容错,但质量均值低持续积累
追逐红利每年切换至当年 argmax(集中度红利 × 趋势),追逐最高 rev_mult每年重置
跟随周期每5年仅在市场趋势切换年(每5年)跟随新趋势类型,中间4年稳定积累5年积累后重置
+
+ + +
+
📊
仿真结论
+

+ 分析场景:开发商 2,000 家 × 发行商 400 家,仿真 30 年,3 个随机种子均值。 +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
策略dev 存活dev 年化dev 期望年化↑pub 存活pub 年化pub 期望年化↑分成主态
跟随周期18.0%+4.11% +
+
+ +0.701% +
+
66.6%+3.61% +
+
+ +2.504% +
+
混合均衡
专注高投入24.9%+2.93% +
+
+ +0.658% +
+
81.1%−6.68% +
+
+ −5.420% +
+
6:4(96%)
追逐红利14.1%+4.22%* +
+
+ +0.593% +
+
58.3%−1.85% +
+
+ −1.072% +
+
混合波动
专注普通15.5%+3.43% +
+
+ +0.537% +
+
65.3%−3.15% +
+
+ −1.482% +
+
5:5(100%)
专注低投入28.9%−0.02% +
+
+ −0.006% +
+
93.4%+2.08% +
+
+ +1.950% +
+
4:6(96%)
+ +

+ * 追逐红利的幸存者年化(+4.22%)受聚集型破产导致的幸存者偏差影响虚高;期望年化(+0.593%)为真实效用。 +

+ +

各策略50年演化轨迹(主场景,seed=42)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
策略年50 开发商AP年50 学习乘数年50 市场压缩幸存者资本市场上限首次触发
跟随周期72.11.0011.000 × (未压缩)35.7 C第 21 年
专注高投入85.01.0540.333 × (打三折)26.8 C第 20 年
追逐红利70.31.0000.665 ×23.4 C第 16 年
专注普通69.61.0450.712 ×24.6 C第 25 年
专注低投入55.21.0480.945 ×7.4 C第 40 年
+
+ + +
+
💡
核心发现
+ +
+
+

跟随周期:唯一双边共赢策略

+

dev 期望 +0.701%,pub 期望 +2.504%,两侧均正。 + 50 年末幸存者资本 35.7C 为全场最高。 + 每5年切换使分成在三档间轮转,平均趋近5:5,规模上限全程近乎不触发。

+
+
+

专注高投入:开发商个体最优,发行商深亏

+

6:4 分成将 dev 存活率推至 24.9%,但同时令市场利润更快超出上限—— + 年 50 时收入仅剩 0.33×。发行商期望 −5.42%,长期无法维持。

+
+
+

追逐红利:幸存者偏差陷阱

+

幸存者年化(+4.22%)看似最高,实为假象:羊群效应导致聚集型破产, + 批量死亡在均值资本中制造统计跳升。期望年化仅 +0.593%,排第三。

+
+
+

专注低投入:高存活,但接近零效用

+

dev 存活率最高(28.9%),发行商存活率高达 93.4%。 + 然而 dev 期望仅 −0.006%,为勉强收支平衡的维持型路线。 + 市场规模压制最轻,属保守仓位而非成长策略。

+
+
+ +
+ 机制权衡: + 专注高投入的"6:4 分成优势"与"规模上限反噬"相互抵消——高投入利润越多,规模上限触发越早越猛, + 反而令50年末幸存者资本(26.8C)低于跟随周期(35.7C)。 + 没有一种专一策略能同时绕开这两重约束。 +
+
+ + +
+

策略建议(以期望年化为主要指标)

+
+
+
双边市场健康(dev + pub)
+
跟随周期
+
唯一双边期望均正,50年末资本最高
+
+
+
最大化开发商 dev 期望收益
+
跟随周期 +0.701%
+
其次专注高投入 +0.658%
+
+
+
最大化发行商 pub 期望收益
+
跟随周期 +2.504%
+
其次专注低投入 +1.950%
+
+
+
最大化开发商存活率(不计收益)
+
专注低投入 28.9%
+
低破产门槛,但期望收益近零
+
+
+
+ 注意: + 追逐红利的幸存者年化(+4.22%)并非真实效用——大多数参与者在赚到利润前就已破产(仅14.1%存活)。 + 期望年化(+0.593%)才是对随机进入者有意义的指标,追逐红利在此指标下排第三。 +
+
+ + + + +
+ + diff --git a/output/downloaded-files/html-md/花园世界产品策略_GOS补充信息.md b/output/downloaded-files/html-md/花园世界产品策略_GOS补充信息.md new file mode 100644 index 0000000..869ceaa --- /dev/null +++ b/output/downloaded-files/html-md/花园世界产品策略_GOS补充信息.md @@ -0,0 +1,53 @@ +# 《我的花园世界》产品策略补充 —— GOS侧信息与内部讨论 + +> 供报告团队参考,以下标注了【已验证数据】和【内部猜测】以示区分。 + +--- + +## 一、用户画像:GOS侧有可参照的验证数据【已验证】 + +- GOS的美国用户群体与花园世界的用户属性有较高重合度 +- GOS已验证了30+女性玩家"合作>竞争、低压>高压"的诉求 + +--- + +## 二、GOS对花园世界机制的实测反馈【已验证】 + +1. GOS简单尝试过种花类买量素材(参考花园世界),点击率和获客成本均没有明显优势。这至少说明:并不是简单复刻花园素材就能获得大量用户,需要深度研判和测试。发行侧目前仍在推进优化中。 + +2. GOS以半个月活动周期,复刻了花园世界的低压力循环+无限制数值消耗原型(无核心GVE和深度社交),营收和口碑高于常规活动。 + +3. GOS将花园世界的GVE拆分为独立活动,预计7月周年庆上线,可以独立观察GVE层在类似用户群上的效果。 + +--- + +## 三、我的花园世界融合中重度运营的可能性【可参考】 + +GOS(女性为主)和GOK(男性为主)均尝试过互相移植成功的玩法原型: + +- GOS融合休闲玩法,GOK融合SLG +- 双方均感受到两个产品玩家诉求存在强差异化和基础矛盾,核心就是竞争与合作的对立,融合中重度运营可能会遇到同样的问题; + +另外,GOS女性用户对超休闲策略小游戏的接受度较高,存在朝超休闲方向拓展用户群的可能性。 + +--- + +## 四、内部关于花园世界的几点猜测【内部猜测,待验证】 + +**1. 吸量问题** + +(1)素材和发行手法导致的差异 + +猜测花园世界的核心吸量是通过送真花类素材实现的,其余素材对比正常题材并无特殊优势。正在调研验证,看看各市场素材分布和效果数据是什么样的。 + +(2)需求缺口与竞争窗口 + +猜测花园世界主要是抓住了女性向用户的需求缺口。如果这个缺口正在被快速填补,导致素材成本快速上升,或者市场规模本身有限,在没有更有吸引力的题材/体验/商业化模型的情况下,直接跟有先发优势和用户基数的花园世界正面竞争,难度较大。 + +**2. 中后期模型迭代空间** + +猜测花园世界中后期可能同样会面临GOS早期遇到的内容填充问题。现有的"抽卡→得新花→GVE验证图鉴"商业化结构上也有迭代空间(类似wsy和GOS在大清基础上迭代),在商业化上有比较大的机会对比原型在长期留存和LTV上做出更高上限。 + +--- + +*以上信息均来自GOS侧数据和内部讨论。标注为猜测的部分均未验证,供报告团队按需参考。* diff --git a/output/downloaded-files/html-md/花园世界等相关产品25.10.28.xlsx b/output/downloaded-files/html-md/花园世界等相关产品25.10.28.xlsx new file mode 100644 index 0000000..8b807d1 Binary files /dev/null and b/output/downloaded-files/html-md/花园世界等相关产品25.10.28.xlsx differ diff --git a/output/downloaded-files/html-md/花园项目对策划的启示.md b/output/downloaded-files/html-md/花园项目对策划的启示.md new file mode 100644 index 0000000..ffe23f0 --- /dev/null +++ b/output/downloaded-files/html-md/花园项目对策划的启示.md @@ -0,0 +1,132 @@ +# 《我的花园世界》研究对公司新项目策划的启示 + +我认为最大的启发不是“去做一个种花游戏”,而是新项目策划要从一开始就设计“可被放大的结构”。 + +--- + +## 1. 立项不要只盯头部,要找可放大的腰部底座 + +《我的花园世界》的价值在于:它不是从零发明新品类,而是识别了《鲜花小镇》《秘密花园HD》已经验证过的底座,然后用更强的美术、营销、商业化、运营能力放大。 + +对新项目策划的启发是,立项阶段应该多问: + +- 有没有某个腰部产品,留存/付费结构不错,但美术、传播、商业化、运营明显没做透? +- 它的核心循环是否已经被用户验证? +- 我们相比原产品,能放大的能力是什么:题材包装、买量素材、社交生态、商业化深度,还是长期运营? + +不要一上来追求“完全原创机制”。很多时候更务实的机会是:**已验证底座 + 更强放大能力**。 + +--- + +## 2. 先设计稳定日常循环,再设计组织目标 + +新项目如果要做长线,不应该先堆公会、排行榜、抽奖、活动,而是先确认日常循环是否稳定: + +`产出资源 → 消耗资源 → 获得成长/展示/社交价值 → 再回到产出` + +《我的花园世界》的强处是,种花、订单、库存、活动、公会竞赛都在争夺同一批花材。玩家不是单纯被“卡”,而是被迫开始做规划。 + +新项目可以借鉴这个思路:核心资源不要只服务一个出口,而要有多个互相竞争的出口,例如: + +- 日常订单消耗 +- 活动目标消耗 +- 公会贡献消耗 +- 装扮/展示消耗 +- 交易/互助消耗 + +这样中期才会自然产生策略、社交和付费需求。 + +--- + +## 3. 非战斗 GVG 值得重点研究 + +它证明了一个重要方向:不是所有 GVG 都必须打架。休闲、模拟、经营、装扮、收集类项目也可以做组织竞争。 + +但关键不是简单加一个公会排行榜,而是要满足几件事: + +- 异步参与:不要求同时在线。 +- 人人有贡献:普通玩家也能提供基础价值。 +- 付费玩家拉高上限,但不能完全碾压。 +- 个人贡献和个人奖励挂钩,减少搭便车。 +- 有低压公会、养老公会、分层赛段,避免轻度玩家被赶走。 + +这对女性向、休闲经营、生活模拟类新项目很有价值。它能把原本偏单机的循环,变成长期社交目标。 + +--- + +## 4. 商业化不要只做“卡点逼氪”,要设计“被需要”的付费理由 + +《我的花园世界》最值得借鉴的是“社交拉氪”的方向:玩家不是单纯因为过不去才付费,而是因为自己在公会、好友、换花关系里有价值。 + +新项目可以设计类似结构: + +- 某些资源天然供需错配。 +- 玩家之间可以互助、交换、贡献。 +- 组织目标需要不同层级玩家共同完成。 +- 付费玩家不是替代普通玩家,而是补足组织上限。 +- 免费玩家也不能被系统边缘化,否则社交生态会塌。 + +商业化设计应从“卖资源”升级为“卖效率、确定性、稀缺身份、组织价值”。 + +--- + +## 5. 增长钩子必须在策划阶段就考虑 + +“种虚拟花,收真实花”不是普通福利,而是一个非常强的传播设计:玩家可以把游戏成果晒到现实社交平台。 + +新项目策划时要提前问: + +- 玩家完成什么行为后,能得到一个“可晒”的结果? +- 这个结果是图、视频、称号、实体物、社交身份,还是可转发的作品? +- 它能不能让玩家说“你看我获得了什么”,而不是只说“这个游戏挺好玩”? +- 这个结果是否适合抖音、小红书、微信传播? + +不一定要做实物奖励。实物履约风险很高。更重要的是找到本品类的“虚拟行为 → 外部可展示结果”。 + +--- + +## 6. 活动系统要早规划节奏,而不是上线后乱堆 + +《我的花园世界》后期形成“四大活动 + 五小活动”的双层错频节奏。启发是:活动体系应该有层次。 + +新项目可以提前规划: + +- 长周期活动:提供长期目标和高价值奖励。 +- 短周期活动:提供变化感和轻玩法。 +- 节日/联动活动:负责回流与传播。 +- 公会周期:负责组织目标。 +- 日常任务:负责稳定登录。 + +不要所有活动都抢同一时间、同一资源、同一入口,否则玩家会信息过载。 + +--- + +## 7. 风险能力也是产品能力 + +如果新项目也想做现实奖励、线下联动、实体兑换,就必须把履约和客服当成核心系统,而不是运营附属。 + +策划阶段就要写清楚: + +- 掉率和门槛是否透明。 +- 兑换流程是否足够短。 +- 配送范围和成本是否可控。 +- 客服 SLA 是多少。 +- 投诉、退款、补偿怎么处理。 +- 实物品质和宣传图是否一致。 + +否则增长钩子会反过来变成信任风险。 + +--- + +## 8. 给新项目策划的直接检查清单 + +立项方案里必须回答这 6 个问题: + +1. 我们借鉴的是哪个已验证底座,而不是只说对标哪个爆款? +2. 这个底座为什么没有被原团队放大? +3. 我们能放大的能力是什么? +4. 核心资源是否有多个消耗出口? +5. 是否能做低压、异步、人人有贡献的组织目标? +6. 玩家有什么结果可以拿到外部平台展示? + +如果这 6 个问题答不清,项目很容易变成“系统很多,但没有放大杠杆”。 diff --git a/output/downloaded-files/html-md/进一步的思考.md b/output/downloaded-files/html-md/进一步的思考.md new file mode 100644 index 0000000..e73a35c --- /dev/null +++ b/output/downloaded-files/html-md/进一步的思考.md @@ -0,0 +1,314 @@ +# 进一步的思考:基于《我的花园世界》研究的立项与产品改进启发 + +基于《我的花园世界》的研究,可以把举一反三分成两类:**新立项思路**和**已有项目改进思路**。 + +## 一、最核心的抽象 + +不要把结论理解成“做种花”或“做真花奖励”。 + +真正有价值的抽象是: + +> 找一个已经被用户验证、但还没有被充分放大的底座,用公司的美术、商业化、运营、发行、社群能力,把它系统性放大。 + +所以立项不是从“题材”开始,而是从这几个问题开始: + +- 哪个中腰部产品证明了一个需求成立? +- 它为什么没做大? +- 它缺的是美术、传播、商业化、长期运营,还是组织生态? +- 我们有没有能力补上这块短板? +- 补上以后,商业规模能不能被放大 5 倍、10 倍甚至更多? + +--- + +## 二、立项思路一:腰部产品放大型 + +这是最直接的启发。 + +找那些不是头部、但结构有潜力的产品,例如: + +- 留存不错,但画面老。 +- 核心循环成立,但商业化浅。 +- 社区活跃,但官方运营弱。 +- 小圈层用户很忠诚,但传播包装差。 +- 有长期目标,但缺活动体系和付费分层。 + +立项方向不是“抄一个爆款”,而是做: + +> 腰部已验证底座 + 更强包装 + 更强运营 + 更深商业化。 + +适合扫描的赛道包括: + +- 休闲经营 +- 宠物养成 +- 家园装扮 +- 手账/收集 +- 美食餐厅 +- 换装社交 +- 轻模拟人生 +- 女性向轻社交 +- 中老年休闲社交小游戏 + +重点不是赛道热不热,而是有没有“结构成立但没被放大”的产品。 + +--- + +## 三、立项思路二:非战斗 GVG 型产品 + +很多项目一想到 GVG 就想到战斗、公会战、抢资源、打排名。但《我的花园世界》证明:**组织竞争不一定需要战斗**。 + +可以围绕这些行为做 GVG: + +- 种植贡献 +- 订单贡献 +- 装修贡献 +- 收集贡献 +- 制作贡献 +- 探索贡献 +- 互助贡献 +- 投票贡献 +- 展示贡献 + +举例: + +- 宠物项目:公会共同照顾动物园、完成救助任务。 +- 餐厅项目:联盟共同筹备宴会、完成订单季赛。 +- 家园项目:社区共同建设街区、参与主题装修赛。 +- 换装项目:社团共同完成秀场主题,成员贡献服饰/票数/搭配。 +- 农场项目:村庄共同完成订单、节庆、贸易目标。 + +核心不是排行榜,而是: + +> 个人日常行为可以异步累积成组织目标。 + +这是休闲项目长线化的重要方向。 + +--- + +## 四、立项思路三:可晒成果型产品 + +《我的花园世界》的增长钩子是“我真的收到花了”。但不是所有项目都要做实物奖励。 + +更通用的思路是: + +> 玩家在游戏里的行为,要能变成一个外部可展示结果。 + +这个结果可以是: + +- 一张好看的图 +- 一个花园截图 +- 一段宠物视频 +- 一份虚拟作品 +- 一个称号身份 +- 一张社交卡片 +- 一个可分享的故事 +- 一个真实权益 +- 一个共同完成的社群成果 + +适合立项的方向: + +- “我养成了什么” +- “我布置了什么” +- “我收集到了什么” +- “我帮团队完成了什么” +- “我获得了某个现实/社交认可” + +这类项目更适合小红书、抖音、微信传播。策划阶段就要考虑“玩家为什么愿意晒”。 + +--- + +## 五、立项思路四:资源错配社交型 + +《我的花园世界》的社交不是纯聊天,而是由资源错配驱动的。 + +玩家 A 缺这种花,玩家 B 有;公会缺某类贡献,某个玩家能补;普通玩家提供基础贡献,付费玩家拉高上限。 + +这给新项目一个通用模型: + +> 资源不完全自给 → 玩家互相需要 → 互助/交易/公会贡献 → 社交关系形成 → 付费理由增强。 + +可迁移到很多品类: + +- 宠物:不同玩家产出不同食材/玩具/照护资源。 +- 餐厅:不同玩家擅长不同菜系/食材。 +- 家园:不同玩家产出不同装饰材料。 +- 换装:不同玩家拥有不同风格部件。 +- 探索:不同玩家获得不同区域资源。 +- 卡牌轻社交:不同玩家持有不同收藏碎片。 + +这比单纯“加好友送体力”更有价值,因为它让玩家真的“被需要”。 + +--- + +## 六、立项思路五:轻题材 + 重后端 + +《我的花园世界》表面是轻题材,后端其实很重:资源规划、公会竞赛、活动轮换、订阅、礼包、累充、抽奖、真实奖励。 + +这说明新项目可以采用一种结构: + +> 前台轻松、情绪友好;后台有深度、有组织、有长期目标、有付费分层。 + +适合女性向、泛用户、休闲项目。 + +但关键是前台不能把重度压力暴露得太早。早期应该让玩家觉得轻松、治愈、可爱;中后期再逐步进入库存规划、组织目标、活动竞争、收藏追求。 + +这对策划节奏很重要:不要一开始就把系统全压给玩家。 + +--- + +## 七、已有项目的改进思路 + +如果不是新立项,而是改已有项目,可以从以下几个方向检查。 + +### 1. 检查核心资源是否只有单一出口 + +很多项目的问题是资源循环太直: + +`产出资源 → 升级 → 继续产出` + +这很快会疲劳。 + +可以改成多出口: + +- 升级要消耗 +- 活动要消耗 +- 公会要消耗 +- 交易要消耗 +- 装扮要消耗 +- 订单要消耗 +- 限时目标要消耗 + +一旦多个出口争夺同一资源,玩家就会开始做规划。规划感出来后,留存、付费、社交才有空间。 + +### 2. 给单机循环加异步组织目标 + +如果项目现在偏单机,可以先不做强 PVP,而是加异步组织目标: + +- 公会订单 +- 联盟建造 +- 团队收集 +- 分段贡献奖励 +- 周期性社团赛 +- 低压排行榜 +- 个人贡献奖励 + +重点是让普通玩家也有价值,而不是只让大 R 决定胜负。 + +### 3. 把付费点从“买资源”升级为“买效率、确定性、身份和贡献” + +传统付费点容易变成“缺什么卖什么”。更好的设计是分层: + +- 低价:免广告、月卡、便捷操作。 +- 中价:活动礼包、成长基金、效率提升。 +- 高价:稀缺资源、冲榜资源、限定收藏。 +- 社交型:帮助公会、补足缺口、提升团队贡献。 + +这样付费动机更丰富,不只依赖卡点。 + +### 4. 增加展示层,而不是只加数值层 + +很多长线项目后期只会继续加数值系统,但玩家真正需要的是“我有什么值得展示”。 + +可以补: + +- 拍照模式 +- 主页展示 +- 好友参观 +- 作品分享 +- 主题赛 +- 收藏墙 +- 成就卡片 +- 社交名片 +- 公会荣誉展示 + +展示层是增长和留存之间的桥。玩家愿意展示,才会愿意长期投入。 + +### 5. 活动系统要形成节奏,不要堆入口 + +已有项目常见问题是活动太多、入口太乱、奖励都差不多。 + +可以改成三层: + +- 日常层:每天稳定上线。 +- 短周期层:3-4 天提供变化。 +- 长周期层:1-2 周提供目标。 +- 节日/联动层:负责回流和传播。 +- 公会层:负责组织关系。 + +活动不是越多越好,而是要让玩家知道“我现在该优先做什么”。 + +--- + +## 八、最值得公司内部沉淀的方法 + +建议把这套研究沉淀成一个立项评估框架。 + +### A. 找底座 + +这个产品或品类是否已经验证: + +- 核心循环成立? +- 用户愿意长期回来? +- 有自然社交或展示需求? +- 有付费用户存在? +- 有社区自发攻略/招新/交流? + +### B. 找短板 + +原产品为什么没做大: + +- 画面老? +- 买量素材弱? +- 商业化浅? +- 活动密度低? +- 社交组织弱? +- 新手体验差? +- 缺展示传播点? + +### C. 找放大能力 + +公司能补什么: + +- 美术升级 +- 题材包装 +- 短视频素材 +- 商业化设计 +- 长线活动 +- 公会生态 +- 数据调优 +- 平台发行 +- 社群运营 + +### D. 找外部传播点 + +玩家能晒什么: + +- 成果 +- 身份 +- 稀缺物 +- 作品 +- 情绪 +- 现实权益 +- 团队荣誉 + +### E. 找风险 + +放大之后最可能出问题在哪里: + +- 履约 +- 客服 +- 活动肝度 +- 大 R 垄断 +- 轻度用户流失 +- 抽奖争议 +- 社群压力 +- 信息过载 + +--- + +## 九、最直接的结论 + +如果用一句话概括: + +> 新项目策划不要只问“玩法新不新”,而要问“这个底座是否已被验证、哪里没被放大、我们能用什么能力放大,以及放大后玩家为什么愿意留下、付费和传播”。 + +这是《我的花园世界》研究对新项目最有价值的启发。 diff --git a/output/downloaded-files/other/game-analyst-agent.zip b/output/downloaded-files/other/game-analyst-agent.zip new file mode 100644 index 0000000..4077505 Binary files /dev/null and b/output/downloaded-files/other/game-analyst-agent.zip differ diff --git a/output/knowledge-graph/knowledge_graph.html b/output/knowledge-graph/knowledge_graph.html new file mode 100644 index 0000000..48cf801 --- /dev/null +++ b/output/knowledge-graph/knowledge_graph.html @@ -0,0 +1,332 @@ + + + + + +知识图谱 - dc战略问题研究院 & 创新组 + + + +
+

知识图谱

+

dc战略问题研究院 & 创新组 | 2026-05-01 ~ 2026-06-02

+ +
+
28
活跃人员
+
190
飞书文档链接
+
18
文件附件
+
7
核心主题
+
377
总消息数
+
+ +

人员图谱

+
+
李志健
121条消息 | dc战略问题研究院, 创新组
+
黄静雯
31条消息 | dc战略问题研究院, 创新组
+
陈楚真
24条消息 | dc战略问题研究院
+
夏莲
22条消息 | dc战略问题研究院
+
王雨默
21条消息 | 创新组
+
张家振
20条消息 | dc战略问题研究院
+
韦译
20条消息 | 创新组
+
胡辉俊
17条消息 | dc战略问题研究院
+
莫润麟
17条消息 | dc战略问题研究院
+
刘鹏
13条消息 | 创新组
+
卓泽
12条消息 | 创新组
+
汪季
11条消息 | dc战略问题研究院
+
上官成
8条消息 | dc战略问题研究院, 创新组
+
路弘阁
6条消息 | dc战略问题研究院
+
徐锐
6条消息 | 创新组
+
傅明游
5条消息 | dc战略问题研究院
+
A
AI小钉
5条消息 | 创新组
+
文健
4条消息 | dc战略问题研究院
+
林峰
3条消息 | dc战略问题研究院
+
安东
2条消息 | dc战略问题研究院, 创新组
+
吴爽
2条消息 | dc战略问题研究院
+
林云龙
1条消息 | dc战略问题研究院
+
韩丹
1条消息 | dc战略问题研究院
+
汪雄军
1条消息 | dc战略问题研究院
+
黄祥钦
1条消息 | dc战略问题研究院
+
林祥武
1条消息 | dc战略问题研究院
+
彭俊豪
1条消息 | dc战略问题研究院
+
曹纲玮
1条消息 | dc战略问题研究院
+
+

核心研究主题

+
+

《我的花园世界》深度研究

+

围绕《我的花园世界》的全方位研究,包括产品机制、商业化、资源经济、竞品对比

+

关键人物: 李志健, 黄静雯, 陈楚真, 傅明游

+
+低压经营 +极致消耗 +非战斗GVG +社交拉氪 +大通服 +腰部底座放大 +
+

关联文件:

+
+
+

云湖工作室项目选择

+

广州云湖工作室第一个转型项目的方向选择分析

+

关键人物: 黄静雯

+
+2个月MVP +AI美术适配 +素材CPI验证 +欧美化花园经营 +
+

关联文件:

+
+
+

Game Analyst Agent 工具

+

通用产品分析自动化工具,自动探索游戏界面、提取机制与数值

+

关键人物: 黄静雯

+
+自动界面探索 +pHash去重 +9级决策链 +多游戏对比 +决策报告生成 +
+

关联文件:

+
+
+

战略思维与方法论

+

李志健关于幸存者偏差、筹码管理、生长逻辑的战略反思

+

关键人物: 李志健

+
+幸存者偏差 +筹码管理 +正期望博弈 +生长逻辑 +非对称博弈 +
+

关联文件:

+
+
+

AI落地与组织变革

+

AI在游戏研发中的实际落地、效率提升与组织变革讨论

+

关键人物: 李志健, 林峰, 汪雄军, 上官成, 安东

+
+AI军备竞赛 +端到端提效 +组织变革 +AI工作小组 +
+
+
+

创新组日报与研发进展

+

创新组成员的每日工作日报,涵盖二合类游戏研发、AI工具使用

+

关键人物: 王雨默, 韦译, 刘鹏, 卓泽, 徐锐

+
+二合类游戏 +AI关卡生成 +UI编辑器 +数值平衡 +竞品分析 +
+

关联文件:

+
+
+

战略组日报与知识产出

+

战略研究组成员每日提交的研究日报

+

关键人物: 黄静雯, 陈楚真, 张家振, 夏莲, 莫润麟, 胡辉俊, 汪季

+
+竞品拆解 +知识卡片 +MECH/REPORT/ORG卡片 +Agent架构 +
+
+

文档分布

+
+
dianchukeji (公司飞书)
98
+
fcnlycv6dd0w (研究组飞书)
56
+
ocnmca6f1o0p (另一飞书空间)
20
+
my.feishu.cn (个人飞书)
9
+
kimi.link
4
+
mp.weixin.qq.com
3
+
+

全部文件附件

+
+ + + + + + + + + + + + + + + + + + + +
文件名分享者群组时间
游戏行业核心观点梳理.pdf李志健dc战略问题研究院2026-05-15 10:28:47
AI视频创作作品分享罗剑豪V3.pptx李志健dc战略问题研究院2026-05-13 14:36:23
坦克大逃杀答辩材料:从代码搬运工到架构师助理.pptx李志健dc战略问题研究院2026-05-13 14:36:02
《仙途乐逍遥》AI歌曲分享文档.xmind李志健dc战略问题研究院2026-05-13 14:35:35
刘亚彬-万剑囚天镇压獓因-分享文档02.pptx李志健dc战略问题研究院2026-05-13 14:34:08
寻仇AI视频制作分享PPT (2).pptx李志健dc战略问题研究院2026-05-13 14:21:13
模型报告.html李志健dc战略问题研究院2026-05-11 01:28:58
game-analyst-agent.zip黄静雯dc战略问题研究院2026-05-22 09:02:50
game-analyst-agent-manual.html黄静雯dc战略问题研究院2026-05-22 09:02:50
2026-05-yunhu-project-selection-strategy-report.html黄静雯dc战略问题研究院2026-05-21 00:35:28
取败之道——关于幸存者偏差、筹码管理与生长逻辑的深度反思.md李志健dc战略问题研究院2026-05-20 10:22:27
花园世界产品策略_GOS补充信息.md傅明游dc战略问题研究院2026-05-26 16:00:45
2026-05-25_report_my_garden_world_us_project.html黄静雯dc战略问题研究院2026-05-26 09:29:12
主报告-我的花园世界.html李志健dc战略问题研究院2026-06-01 23:36:40
进一步的思考.md李志健dc战略问题研究院2026-06-01 23:09:45
花园项目对策划的启示.md李志健dc战略问题研究院2026-06-01 22:55:36
花园世界等相关产品25.10.28.xlsx李志健dc战略问题研究院2026-06-01 21:42:33
工作流总结-王雨默.html王雨默创新组2026-05-22 10:57:31
+

关键概念索引

+
+2个月MVP -> 云湖工作室项目选择 +
+
+9级决策链 -> Game Analyst Agent 工具 +
+
+AI关卡生成 -> 创新组日报与研发进展 +
+
+AI军备竞赛 -> AI落地与组织变革 +
+
+AI工作小组 -> AI落地与组织变革 +
+
+AI美术适配 -> 云湖工作室项目选择 +
+
+Agent架构 -> 战略组日报与知识产出 +
+
+MECH/REPORT/ORG卡片 -> 战略组日报与知识产出 +
+
+UI编辑器 -> 创新组日报与研发进展 +
+
+pHash去重 -> Game Analyst Agent 工具 +
+
+二合类游戏 -> 创新组日报与研发进展 +
+
+低压经营 -> 《我的花园世界》深度研究 +
+
+决策报告生成 -> Game Analyst Agent 工具 +
+
+多游戏对比 -> Game Analyst Agent 工具 +
+
+大通服 -> 《我的花园世界》深度研究 +
+
+幸存者偏差 -> 战略思维与方法论 +
+
+数值平衡 -> 创新组日报与研发进展 +
+
+极致消耗 -> 《我的花园世界》深度研究 +
+
+欧美化花园经营 -> 云湖工作室项目选择 +
+
+正期望博弈 -> 战略思维与方法论 +
+
+生长逻辑 -> 战略思维与方法论 +
+
+知识卡片 -> 战略组日报与知识产出 +
+
+社交拉氪 -> 《我的花园世界》深度研究 +
+
+竞品分析 -> 创新组日报与研发进展 +
+
+竞品拆解 -> 战略组日报与知识产出 +
+
+端到端提效 -> AI落地与组织变革 +
+
+筹码管理 -> 战略思维与方法论 +
+
+素材CPI验证 -> 云湖工作室项目选择 +
+
+组织变革 -> AI落地与组织变革 +
+
+腰部底座放大 -> 《我的花园世界》深度研究 +
+
+自动界面探索 -> Game Analyst Agent 工具 +
+
+非对称博弈 -> 战略思维与方法论 +
+
+非战斗GVG -> 《我的花园世界》深度研究 +
+
\ No newline at end of file diff --git a/output/knowledge-graph/knowledge_graph.json b/output/knowledge-graph/knowledge_graph.json new file mode 100644 index 0000000..9156d16 --- /dev/null +++ b/output/knowledge-graph/knowledge_graph.json @@ -0,0 +1,4495 @@ +{ + "metadata": { + "generated": "2026-06-02", + "groups": [ + "dc战略问题研究院", + "创新组" + ], + "time_range": "2026-05-01 ~ 2026-06-02", + "total_messages": 377 + }, + "persons": { + "李志健": { + "name": "李志健", + "groups": [ + "dc战略问题研究院", + "创新组" + ], + "contributions": 121, + "dingtalk_id": "DiiwgzU0OGm82ueZDWYBV2oCaDOSt3glho" + }, + "胡辉俊": { + "name": "胡辉俊", + "groups": [ + "dc战略问题研究院" + ], + "contributions": 17, + "dingtalk_id": "DiiwgzU0OGm80JxMWhsMTUfiPmKsvI0Z2cq" + }, + "夏莲": { + "name": "夏莲", + "groups": [ + "dc战略问题研究院" + ], + "contributions": 22, + "dingtalk_id": "DiiwgzU0OGm80ctHYH5LKsx85DLu66yiSyl" + }, + "莫润麟": { + "name": "莫润麟", + "groups": [ + "dc战略问题研究院" + ], + "contributions": 17, + "dingtalk_id": "DiiwgzU0OGm83qaYrnniPXnJJEX3jTepF1L" + }, + "陈楚真": { + "name": "陈楚真", + "groups": [ + "dc战略问题研究院" + ], + "contributions": 24, + "dingtalk_id": "DiiwgzU0OGm81H0iSNsn6TiP2iSM2aoK0dduq" + }, + "张家振": { + "name": "张家振", + "groups": [ + "dc战略问题研究院" + ], + "contributions": 20, + "dingtalk_id": "DiiwgzU0OGm800e1WXiPKiifiiKrwOPo3LZc9" + }, + "黄静雯": { + "name": "黄静雯", + "groups": [ + "dc战略问题研究院", + "创新组" + ], + "contributions": 31, + "dingtalk_id": "DFCqFh28PT00xAxKsqoT822uuG9ybteAiP" + }, + "路弘阁": { + "name": "路弘阁", + "groups": [ + "dc战略问题研究院" + ], + "contributions": 6, + "dingtalk_id": "DiiwgzU0OGm81ShqiSN886PRKaXwX0uFGNs" + }, + "林云龙": { + "name": "林云龙", + "groups": [ + "dc战略问题研究院" + ], + "contributions": 1, + "dingtalk_id": "DiiwgzU0OGm83qhPjAA1ry1uW2rsjgSm7M" + }, + "韩丹": { + "name": "韩丹", + "groups": [ + "dc战略问题研究院" + ], + "contributions": 1, + "dingtalk_id": "DvPFGhPaGRnZFC0YBNuj3iSUxTtq2KndX9" + }, + "林峰": { + "name": "林峰", + "groups": [ + "dc战略问题研究院" + ], + "contributions": 3, + "dingtalk_id": "DiiwgzU0OGm83XmAiSvnw9uWJ62cBGjiPlHR" + }, + "汪雄军": { + "name": "汪雄军", + "groups": [ + "dc战略问题研究院" + ], + "contributions": 1, + "dingtalk_id": "DG7MRH8ZZvkKPKqQnpPiS2QmuuG9ybteAiP" + }, + "上官成": { + "name": "上官成", + "groups": [ + "dc战略问题研究院", + "创新组" + ], + "contributions": 8, + "dingtalk_id": "DotiPnVQfFYfzJo3iiaFbHUdmuuG9ybteAiP" + }, + "汪季": { + "name": "汪季", + "groups": [ + "dc战略问题研究院" + ], + "contributions": 11, + "dingtalk_id": "DiiwgzU0OGm81sr9Uy8qanOFjiPKKf5xQo8" + }, + "黄祥钦": { + "name": "黄祥钦", + "groups": [ + "dc战略问题研究院" + ], + "contributions": 1, + "dingtalk_id": "DqTn5G2M4og3Jo3iiaFbHUdmuuG9ybteAiP" + }, + "傅明游": { + "name": "傅明游", + "groups": [ + "dc战略问题研究院" + ], + "contributions": 5, + "dingtalk_id": "DiiwgzU0OGm83TqYEWBcmnp0pf7s5SevHC" + }, + "林祥武": { + "name": "林祥武", + "groups": [ + "dc战略问题研究院" + ], + "contributions": 1, + "dingtalk_id": "DiiwgzU0OGm82DxpdfvcWFmii6w9x61plrK" + }, + "安东": { + "name": "安东", + "groups": [ + "dc战略问题研究院", + "创新组" + ], + "contributions": 2, + "dingtalk_id": "DiiwgzU0OGm82iSBr7odfh0EF9Y9MrPkrwT" + }, + "吴爽": { + "name": "吴爽", + "groups": [ + "dc战略问题研究院" + ], + "contributions": 2, + "dingtalk_id": "DiiwgzU0OGm80zcJpB9pLREaWiigQCq4GfK" + }, + "文健": { + "name": "文健", + "groups": [ + "dc战略问题研究院" + ], + "contributions": 4, + "dingtalk_id": "DiiwgzU0OGm81njp7e384qkulEkoh69oag" + }, + "彭俊豪": { + "name": "彭俊豪", + "groups": [ + "dc战略问题研究院" + ], + "contributions": 1, + "dingtalk_id": "DtjUoqCiS01FqdzwnjchBYoGuuG9ybteAiP" + }, + "曹纲玮": { + "name": "曹纲玮", + "groups": [ + "dc战略问题研究院" + ], + "contributions": 1, + "dingtalk_id": "DiiwgzU0OGm83zOd35YPpdk421HiPLhqILF" + }, + "王雨默": { + "name": "王雨默", + "groups": [ + "创新组" + ], + "contributions": 21, + "dingtalk_id": "DiiwgzU0OGm83Omfqe2Z1ufLiPaX3PEEVxs" + }, + "刘鹏": { + "name": "刘鹏", + "groups": [ + "创新组" + ], + "contributions": 13, + "dingtalk_id": "DiiwgzU0OGm83zjMiPxmsg33aPaTc7AWdwd" + }, + "韦译": { + "name": "韦译", + "groups": [ + "创新组" + ], + "contributions": 20, + "dingtalk_id": "DiiwgzU0OGm80upGRstbmdWpx7uvqV9Q31" + }, + "徐锐": { + "name": "徐锐", + "groups": [ + "创新组" + ], + "contributions": 6, + "dingtalk_id": "DiiwgzU0OGm80a7mlIZFktXRWiSnEp8Yfqk" + }, + "卓泽": { + "name": "卓泽", + "groups": [ + "创新组" + ], + "contributions": 12, + "dingtalk_id": "DiiwgzU0OGm83xKgxtzJGSBCiiEBXYAD1MF" + }, + "AI小钉": { + "name": "AI小钉", + "groups": [ + "创新组" + ], + "contributions": 5, + "dingtalk_id": "DiiwgzU0OGm80qjlLs9LjWa1KiSnWVmQpqn" + } + }, + "documents": [ + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/ErwhdZhR3oJjoNxGB85cQBicnge", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "胡辉俊", + "first_shared": "2026-05-19 01:11:08", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/KlGYddZoOo2UD9xIEVgcNqQ3n5c", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-19 01:10:55", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/YEAcwAuHkiGwngk4z48cLBzWnth", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "莫润麟", + "first_shared": "2026-05-19 01:10:51", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/SFrYdULAvo9Z1oxVUHvcReOcncW", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "陈楚真", + "first_shared": "2026-05-18 23:55:05", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/FFlCweEYqiBlPPkSUzHc1S6bnIc", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-17 01:36:07", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/TXNAdSOe2oLdrLxYswZckoR9nUd", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-17 01:36:02", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/V9ejdL4QBo6XpZxWxPDcVNRMnNh", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-17 01:35:58", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/GcKkd0H5EoQY9KxKiSVcZ05VnVc", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "胡辉俊", + "first_shared": "2026-05-16 02:02:49", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/JfNIdEbJ3o9QLOxlaHzcs7X7nkh", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-16 02:02:48", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/FdI2woTLai6GPDkpPqrcFXYZnGh", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "莫润麟", + "first_shared": "2026-05-16 02:02:25", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/MKv7w5MX5iW54ykkM7Vcfu6YnTg", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-16 01:51:05", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/M8TId6mhhooxZJxHVc5cAwwXnJh", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "黄静雯", + "first_shared": "2026-05-16 01:44:16", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/SPnWddkXkoY8GaxIUyocufXBngh", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "陈楚真", + "first_shared": "2026-05-16 01:42:02", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://mp.weixin.qq.com/s/zNv6MNhcXeuGFvFBD4vSzQ", + "type": "weixin_article", + "domain": "mp.weixin.qq.com", + "shared_by": "李志健", + "first_shared": "2026-05-15 09:08:57", + "group": "dc战略问题研究院", + "context": "[分享] 又一款大厂SLG确定了!这一次不是三国题材,颠覆盟战规则? 又一款SLG 游戏确定了,这一次不是三国题材。这次发布的厂商是风华游戏集团,他们在官方公众号的标题里直接写到:要打造一款“由玩家关", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/SOaBdskVhoSXo0x6gvbcLnKHntb", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "黄静雯", + "first_shared": "2026-05-15 09:02:29", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/BbYMdLdBzoVunRxj51ZcP7gxnFd", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "胡辉俊", + "first_shared": "2026-05-15 01:46:08", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/LxmkwF7MRiUJInk3V6Mcn5Xanfu", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "莫润麟", + "first_shared": "2026-05-15 01:45:54", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/HkYPwjIpBiQFeVknIqac7pk4n0e", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-15 01:45:53", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/HnNgdyIxso9WWYxCCPLcktDTnLh", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-15 01:45:47", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/V9fzdn7fZoTSaGxX7yhcwTQUnFc", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "陈楚真", + "first_shared": "2026-05-15 00:36:28", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/GuJRdtHTKoQ8QaxVbGecxhuDn5Q", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "黄静雯", + "first_shared": "2026-05-14 09:29:52", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/ZgePwV6s4iMUL0kYiwjcr8ZWnIy", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-14 02:01:40", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/EfDVwSBQIipcL1kG21TcP1ZinKf", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "莫润麟", + "first_shared": "2026-05-14 02:01:27", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/BRyrdjvPboqbX2xjQb4cZnBqnde", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "胡辉俊", + "first_shared": "2026-05-14 02:01:15", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/GaBtddjSqoukwVxGYavcp31zn0e", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-14 02:01:02", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/Eie1dKsSpoYQkjxUlvdcc5Yknff", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "陈楚真", + "first_shared": "2026-05-14 01:22:31", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/AhYwdapYjo9Elkx2giXczIK2nno", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "陈楚真", + "first_shared": "2026-05-13 10:08:50", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/ExYndBzwSoEobXxqgiicDkionnh", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "黄静雯", + "first_shared": "2026-05-13 02:58:37", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/BVdywLGYyiZFTXkS2nWcHoQ6nmf", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "莫润麟", + "first_shared": "2026-05-13 01:32:57", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/RKktdFgpDovfSJxcDJpcjbbEnHg", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "胡辉俊", + "first_shared": "2026-05-13 01:29:02", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/W0bjwALE3i2EfSkUxIZcXxtTnAb", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-13 01:28:58", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/Kv25dB4ecoMey9xrTZ6cr3REnbc", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-13 01:28:44", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/XneKwLxUmilaOmkJh8fcRPMInOe", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-12 01:13:54", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/Kxkpd6g4Fouc57xQqDucSRQznPe", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "胡辉俊", + "first_shared": "2026-05-12 01:11:02", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/MgDbwesIkiw7dHkK9YFc3G4Jn8d", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "莫润麟", + "first_shared": "2026-05-12 01:10:56", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/OEOqdSIqFoAWvFxuI2gcz9K4ndc", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-12 01:10:47", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/N6J5duouUo2ip7xlyBdcJbkYnxg", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "黄静雯", + "first_shared": "2026-05-12 00:57:55", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/Me8ed6Rfso05rDxG0yBcDfU5n17", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "黄静雯", + "first_shared": "2026-05-10 03:33:49", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/TLAxdvBokob4xlxlLnHc7VXqnFb", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "陈楚真", + "first_shared": "2026-05-10 02:48:38", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/LqVQwLuFLiQdamkOchPczt7dnVh", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-10 02:00:58", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/FA0FdvarioMIgBx9Swjc4AhWnQe", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "胡辉俊", + "first_shared": "2026-05-10 01:54:14", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/HAt8dakuAox8SQxgZdecY07wnzg", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-10 01:54:05", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/F0D7wBPASiKt6okdbQWcLGdYnIO", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "莫润麟", + "first_shared": "2026-05-10 01:53:59", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/UNLydXXQNoGXUCxejlXczf5CnVh", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "黄静雯", + "first_shared": "2026-05-09 03:31:23", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/UHHWdXKNiowKsExi7hlc4t8rnmb", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "陈楚真", + "first_shared": "2026-05-09 01:14:10", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/YELvw8sX7iQZGlkZXZRc6iGWnLF", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-09 01:00:48", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/CmznwoDzIi2nLlkCBxTcyd4nnhe", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-09 01:00:31", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://mp.weixin.qq.com/s/v2NeY6mXfVGIjdRLj3t3xw", + "type": "weixin_article", + "domain": "mp.weixin.qq.com", + "shared_by": "李志健", + "first_shared": "2026-05-24 08:34:35", + "group": "dc战略问题研究院", + "context": "[分享] 游戏行业的两极分化,今年开始要刹不住车了 何去何从?", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/LG5ldIeI1obdMXxpPfTc1NWsnsD", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "胡辉俊", + "first_shared": "2026-05-24 01:46:20", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/BaZIwUkMli87D4k9raUcuWSBnXe", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-24 01:45:48", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/WYvIwdviniPm7MkpPW7c9IYFnbe", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "莫润麟", + "first_shared": "2026-05-24 01:33:42", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/BrBUdkTEPoCjsCxtxDWcBFsungg", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-24 01:33:31", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://my.feishu.cn/wiki/QR6uwinsWikNQnkiQrzcvtUnnDe", + "type": "wiki", + "domain": "my.feishu.cn (个人飞书)", + "shared_by": "汪季", + "first_shared": "2026-05-24 01:29:49", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/IJHCdrFJFo3NPfx6wxDcyFV1n1d", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "黄静雯", + "first_shared": "2026-05-23 03:07:40", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/E2HawE4f1iAB0dkJhCEc98AHnDd", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "陈楚真", + "first_shared": "2026-05-23 03:07:03", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/UvZwwsHu5iXkShkNBMacFTrOnEf", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-23 02:27:51", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/G3aYd9fHVoYMJExAVSwc6ATdnsF", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "胡辉俊", + "first_shared": "2026-05-23 02:13:55", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://my.feishu.cn/wiki/RBrcwhIgeiZJGukUxf0c8MXXnSf", + "type": "wiki", + "domain": "my.feishu.cn (个人飞书)", + "shared_by": "汪季", + "first_shared": "2026-05-23 02:13:30", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/VTaRwgxaOiugwykJAxJcxlsxngf", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "莫润麟", + "first_shared": "2026-05-23 02:05:42", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/IkuadVafvogYbExdqk8ck87nnCf", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-23 02:05:28", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/ZsCbddh64o2rzkxmDn7cTDK1nUq", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "黄静雯", + "first_shared": "2026-05-22 09:02:50", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://my.feishu.cn/wiki/URutwqGDMibG2ekxaVxc0wn3nRe", + "type": "wiki", + "domain": "my.feishu.cn (个人飞书)", + "shared_by": "汪季", + "first_shared": "2026-05-22 02:31:02", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/NBfLdojWgo2vWkxyyGscbOwcnGd", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "胡辉俊", + "first_shared": "2026-05-22 02:23:02", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/Uy6lwM3AtirLc8k9ZsgcO1KtnFg", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-22 02:22:40", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/PdyKdQnAGoKyrAxBXCocypJgnob", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-22 02:22:35", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/DeOCwJ8GZibah7ktWnmcChjEnWf", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "莫润麟", + "first_shared": "2026-05-22 02:22:27", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/Etv3dHq9QoZFJuxhAz3cFaVlnIe", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "陈楚真", + "first_shared": "2026-05-22 01:34:57", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/UzkTwgGABiD5xwkfiJ8cmgzfnyf", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-21 03:56:42", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://my.feishu.cn/wiki/JIKHw6Ev6iTjCyk43vAcjNrNnmc", + "type": "wiki", + "domain": "my.feishu.cn (个人飞书)", + "shared_by": "汪季", + "first_shared": "2026-05-21 02:21:54", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/NnBBdPLZZo24Q5xkzbTcObbMnnd", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "胡辉俊", + "first_shared": "2026-05-21 02:20:36", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/OoRZwAfKLiodpnkVIqgcSCXcn35", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "莫润麟", + "first_shared": "2026-05-21 02:16:15", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/QlJydJMAQoLN0KxyWeMcRhCcnub", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-21 02:16:06", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/MWYJd6O6Fo7tLyxJ1s8crV7mn3b", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "陈楚真", + "first_shared": "2026-05-21 00:55:38", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://my.feishu.cn/docx/QBIbdTcbdoiHYlxI3MocFnQnn3d", + "type": "docx", + "domain": "my.feishu.cn (个人飞书)", + "shared_by": "汪季", + "first_shared": "2026-05-20 02:22:22", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/KatHwC7e1itotVkGyMFctkiznif", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "莫润麟", + "first_shared": "2026-05-20 02:22:19", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/Y97Sdof7MoVPDgxVdygcGbrJnme", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "胡辉俊", + "first_shared": "2026-05-20 02:22:11", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/ACLuwapXRiUYX8ktOaNceqftn4g", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-20 02:22:07", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/GjzAdQq32orBdxxNX2WcIFCVnBg", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-20 02:22:02", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/EaIkdelyzoLhlYxQ3KAc7NyUnEf", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "陈楚真", + "first_shared": "2026-05-20 00:55:59", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/RX9Sd12rzodPlgxpkQ5cFRgsnJf", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "黄静雯", + "first_shared": "2026-05-28 09:29:46", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/IfTVdH0X7oAM2kxnQmpciEm4nEh", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-28 01:58:21", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/Wm7rdpGchogKJ0xKoptcdacjnbd", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "胡辉俊", + "first_shared": "2026-05-28 01:58:04", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/ENbiwCwG3iyHywk6HqqcsFvYnzd", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-28 01:51:27", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/Euhbwrg5Ti3BLnkk6VEctad8nze", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "莫润麟", + "first_shared": "2026-05-28 01:49:06", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://my.feishu.cn/wiki/TqiTwBgcmimpc6kDB7Fcf9jkngb", + "type": "wiki", + "domain": "my.feishu.cn (个人飞书)", + "shared_by": "汪季", + "first_shared": "2026-05-28 01:48:47", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://upy4l3m3qnegc.ok.kimi.link/", + "type": "kimi", + "domain": "kimi.link", + "shared_by": "陈楚真", + "first_shared": "2026-05-28 01:31:10", + "group": "dc战略问题研究院", + "context": "[分享] 我的花园世界 - 资源经济深度研究", + "share_count": 3 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/AbLed72FgoPn5hxOYN3cRpffn0E", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "陈楚真", + "first_shared": "2026-05-28 01:31:10", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/KC8NdkY8zo5yspxjYqOcA6kenbh", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "胡辉俊", + "first_shared": "2026-05-27 01:51:22", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/B9Ofw7pPVix7FFk2XzOcyGoRnlc", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-27 01:51:21", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/CRV1dW7OtoFhVixTuskcvXiGn6d", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-27 01:51:18", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/R9ciwHpaiiNECoktn2WcD4D9nmh", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "莫润麟", + "first_shared": "2026-05-27 01:51:18", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/FTO7d8y5BoBDj9xDQWHcWcmSn5W", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "黄静雯", + "first_shared": "2026-05-27 01:26:59", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/GNtTdHLGuoSXITxbRhrc8AH1nxd", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "陈楚真", + "first_shared": "2026-05-27 00:54:49", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://kblb6hdbtbfto.ok.kimi.link/", + "type": "kimi", + "domain": "kimi.link", + "shared_by": "陈楚真", + "first_shared": "2026-05-27 00:54:49", + "group": "dc战略问题研究院", + "context": "[分享] 《我的花园世界》商业化梳理报告——基于游戏机制以及社区舆论", + "share_count": 3 + }, + { + "url": "https://my.feishu.cn/wiki/JnfTwTmHni7AswkXSHXcAkn3nKg", + "type": "wiki", + "domain": "my.feishu.cn (个人飞书)", + "shared_by": "汪季", + "first_shared": "2026-05-27 00:42:40", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/RjAtde0SKoIhIRxlwhjcdahtnng", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "黄静雯", + "first_shared": "2026-05-26 09:29:12", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/DHGxwhwGYiBturk1S0xcrmyynre", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-26 03:21:09", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/LOJxdNfW0ohzGlxfDfAc9qIOnyb", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "陈楚真", + "first_shared": "2026-05-26 01:14:47", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/FeE7dAr3gofk83x2kb0cvbFMnMh", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "胡辉俊", + "first_shared": "2026-05-26 00:40:25", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://my.feishu.cn/wiki/DTYiwxNROiJM7tkLjigcYnoGnLc", + "type": "wiki", + "domain": "my.feishu.cn (个人飞书)", + "shared_by": "汪季", + "first_shared": "2026-05-26 00:16:05", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/TDX6wo4WNifFP7kN0ZjcH5RfnMf", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-25 23:41:19", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://upy4l3m3qnegc.ok.kimi.link/#/long-term-study", + "type": "kimi", + "domain": "kimi.link", + "shared_by": "陈楚真", + "first_shared": "2026-06-02 01:24:43", + "group": "dc战略问题研究院", + "context": "", + "share_count": 1 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/FWfQd4Xl6ojWh5xu87rcOIq4nye", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "陈楚真", + "first_shared": "2026-06-02 01:24:43", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/BOWJwOqOxiARunkCc9Ac3nKwnZS", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-06-02 01:16:09", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/SuswdF3rRoSXxfxARbDc7dvcnrb", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-06-02 01:14:15", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/YZ5YwmNz5iDs1NkfdAGcYVs1nsb", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "莫润麟", + "first_shared": "2026-06-02 01:01:08", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/I7ctwab3oir9N7kDZvDcvHRRn5b", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-30 23:54:09", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/V0bnwxo30iKE4DkJDfvcZHmenZe", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-30 23:53:39", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://mp.weixin.qq.com/s/pzNCZB4wF5bgfVfaY-hXug", + "type": "weixin_article", + "domain": "mp.weixin.qq.com", + "shared_by": "曹纲玮", + "first_shared": "2026-05-30 16:48:06", + "group": "dc战略问题研究院", + "context": "[分享] 这个在Steam闷声发财的新兴赛道,可以让很多小游戏“叫爸爸” 你就学吧", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/RWPNdPKz6oFaIdxR72VcTQuunWf", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "黄静雯", + "first_shared": "2026-05-30 09:33:56", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/Wxy6wiZA7iCtc3kdOnPcegbCnCf", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-30 00:45:02", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/JgLtwJ0i2iKz1jkGM7dcZMjCnJb", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "莫润麟", + "first_shared": "2026-05-30 00:44:53", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/W9JEdW0sEo9C6kxgQA3cqjuzn9g", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "胡辉俊", + "first_shared": "2026-05-30 00:44:45", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/W1YTdTk8zomsYVxGrHncV5fhnMc", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-30 00:44:41", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/SpAZdH9xPouOahxabcYcviasn8a", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "陈楚真", + "first_shared": "2026-05-30 00:43:19", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://upy4l3m3qnegc.ok.kimi.link/#/activity-study", + "type": "kimi", + "domain": "kimi.link", + "shared_by": "陈楚真", + "first_shared": "2026-05-30 00:43:19", + "group": "dc战略问题研究院", + "context": "", + "share_count": 1 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/Zz8tdoWkKo50raxxmhCcdsVvn0f", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "黄静雯", + "first_shared": "2026-05-29 09:30:19", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/docx/MdXEdYE2WoNsIpxOmbBcFwX6nNe", + "type": "docx", + "domain": "dianchukeji (公司飞书)", + "shared_by": "陈楚真", + "first_shared": "2026-05-29 02:36:25", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/wiki/WA7NwR9zNiDw7ZkiVQecFbXGnqd", + "type": "wiki", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "莫润麟", + "first_shared": "2026-05-29 02:14:01", + "group": "dc战略问题研究院", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://ocnmca6f1o0p.feishu.cn/wiki/Cl9mwzbAKiKgGskU2rIcNLTOnid", + "type": "wiki", + "domain": "ocnmca6f1o0p (另一飞书空间)", + "shared_by": "张家振", + "first_shared": "2026-05-29 02:13:33", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/J0BldrUWroGsUbx9SRocVrwJnNh", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "夏莲", + "first_shared": "2026-05-29 02:13:23", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://fcnlycv6dd0w.feishu.cn/docx/MOAHdPtZmo75rxxE71IcW1iwnsb", + "type": "docx", + "domain": "fcnlycv6dd0w (研究组飞书)", + "shared_by": "胡辉俊", + "first_shared": "2026-05-29 00:07:34", + "group": "dc战略问题研究院", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/FYKlwX7D5ibbmSkaVMucgKAWnOe", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-06-02 03:15:57", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/PY6mwULmXiWbhEkpO3wcYjPCnrh", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "刘鹏", + "first_shared": "2026-06-01 22:44:23", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/PuiOw5HETi9pnekp6wlctOIvn0c", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "韦译", + "first_shared": "2026-06-01 22:44:11", + "group": "创新组", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/EIWNwKjnIipmStkzIr1cd1kTnPf", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-29 23:22:06", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/G5cPwiVSUiGzkrk2ZIzcP24hn0b", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "刘鹏", + "first_shared": "2026-05-29 21:27:07", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/N4MdwTuQAiPyGRkHWJPcuyeInpf", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "韦译", + "first_shared": "2026-05-29 21:01:23", + "group": "创新组", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/BGn2w5h1Vi8LVWkSzwbcp4xKnNf", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-29 00:09:28", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/FVJ6w0RZFirH9tk7uA4ctqQTn1d", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "韦译", + "first_shared": "2026-05-28 22:39:42", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/HVxhwFfM2idMx7kTiuBcgVBXnCb", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "刘鹏", + "first_shared": "2026-05-28 22:30:28", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/Hv4uwS6U9iqN1skMIKIczOgAnKb", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-28 01:20:32", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/Qn6Cw8OgmiBohUkweYCcPnLpnLb", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "刘鹏", + "first_shared": "2026-05-27 22:05:15", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/Xd60wq12vi5tAUkx1NmcZdE4nrc", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "韦译", + "first_shared": "2026-05-27 22:01:25", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/Y42iwXAsXigSyfkF6bXc5UkLnyb", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-27 00:30:53", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/CDoOwO5ppif43Ak6Lx9cWGMensf", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "刘鹏", + "first_shared": "2026-05-26 22:30:51", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/SuymwQjFYimgnRkZRePcIW0PnWe", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "韦译", + "first_shared": "2026-05-26 22:09:01", + "group": "创新组", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/Mx4SwTP4HiQNISkrygQcGk9jnIe", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-26 00:17:36", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/HuUIwA39fi3UsqkdfhTcE9hRnde", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "韦译", + "first_shared": "2026-05-25 22:30:17", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/KoXGwnkJaiO7q8kah6WcAGmvn0l", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "刘鹏", + "first_shared": "2026-05-25 22:29:38", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/Bf4mwuFU9in51RksjDDc5Fdgnag", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-23 00:57:23", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/DcOkwuOj6iPvdWkaFD1clKuRnAB", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "韦译", + "first_shared": "2026-05-22 22:39:12", + "group": "创新组", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/VCZAwd24fiQIHdk9nrdcKR9TnWg", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "刘鹏", + "first_shared": "2026-05-22 22:29:44", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/RIhawaIYwiBGHak7YAVcaSapnTe", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "徐锐", + "first_shared": "2026-05-22 19:22:14", + "group": "创新组", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/SmxzwvhHOi0rk1kSXxmcMobGnGd", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "徐锐", + "first_shared": "2026-05-22 11:00:22", + "group": "创新组", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/MObLwsaWoirykyke8NXcFUlhnfd", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "刘鹏", + "first_shared": "2026-05-22 10:59:53", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/YniYwtxAiiKqcmkmVM5clNxTnQf", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "韦译", + "first_shared": "2026-05-22 10:57:59", + "group": "创新组", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/ZVOVw5BCriBcUfkT1cFcOw3nnBc", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-22 00:21:29", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/AjK2wPpI7iOFo5kOImVcEe1WnNS", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "韦译", + "first_shared": "2026-05-21 23:13:47", + "group": "创新组", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/F05nwzkQ0ioUxRkNaV8cEBvzn6b", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "刘鹏", + "first_shared": "2026-05-21 22:35:51", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/Qad6w4jY9iweK5kggeCcLkifnIN", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "徐锐", + "first_shared": "2026-05-21 21:57:45", + "group": "创新组", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/JY56wsBHniMVP6k7y7scQ4gUnOg", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "韦译", + "first_shared": "2026-05-21 01:13:40", + "group": "创新组", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/FMV0w4C8ai0oJXkxzhFcygeqnQB", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-21 01:06:56", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/IM5zwpPKUixJBUkninjccrl0njg", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "刘鹏", + "first_shared": "2026-05-20 21:45:20", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/AqzvwhCH9iKYfbkQ5iacMuKJnMe", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "徐锐", + "first_shared": "2026-05-20 19:41:35", + "group": "创新组", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/XRMpwLyT6i55YykYcZScuyRWnyh", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-20 04:22:08", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/ZdTPwDH8NiSh09kOuHicQvLSnZd", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "卓泽", + "first_shared": "2026-05-20 01:28:09", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/KGMJwIMWOiMnnVk2wyrc0OaRnkh", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "韦译", + "first_shared": "2026-05-19 20:41:01", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/DTPlwRI46iKAgfkKvozcBHF1n7c", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "刘鹏", + "first_shared": "2026-05-19 20:38:21", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/OY6KwrH1Rifryrk80nSc4aRPnig", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "徐锐", + "first_shared": "2026-05-19 20:12:20", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/WiBfwLPy1iBhk5kHfQPccx2un0f", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "卓泽", + "first_shared": "2026-05-19 02:10:37", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/PXVywSG2bisQxskF9i1cQSqGndb", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "韦译", + "first_shared": "2026-05-18 20:58:05", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/ZCzDwSm2Mi8cJJkIeHucbbcun54", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "刘鹏", + "first_shared": "2026-05-18 20:03:00", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/KQ98wIYoJiljDFkoqrfcXf5bnme", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "徐锐", + "first_shared": "2026-05-18 18:59:00", + "group": "创新组", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/NSL8whlPbi4Bcmkr0xfcnVcLnxc", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "韦译", + "first_shared": "2026-05-18 14:05:56", + "group": "创新组", + "context": "?from=from_copylink\n\n这个是之前遇到并解决的一些开发环境问题,新同学可以参考一下", + "share_count": 1 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/VQxswUOvaiUx36kPiq6cNBERnLg", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-16 00:53:59", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/WnGawSdJHixT8NkzanRc2JsFnbg", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "韦译", + "first_shared": "2026-05-15 23:57:00", + "group": "创新组", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/QWWCwp79SiwAV2ky2RDcufDCnxe", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "卓泽", + "first_shared": "2026-05-15 23:04:17", + "group": "创新组", + "context": "[?from=from_copylink](?from=from_copylink)", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/XylZwP9vcirf8bkffnjcbN1onpf", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "卓泽", + "first_shared": "2026-05-15 00:11:41", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/QAdawW4l4iaWSIkf0jDcqVxqngb", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-14 23:30:28", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/OqVjwMswbiMXHukGZZZcc9g3nnc", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "韦译", + "first_shared": "2026-05-14 21:49:03", + "group": "创新组", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/DSD4wa3wBiXGxqkg87icUiHHnoe", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "韦译", + "first_shared": "2026-05-14 01:15:59", + "group": "创新组", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/VFeCwF4VsizD4Bkri2Rc62junbf", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-14 00:05:02", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/GfgYwRD7Yiyac0kVWOtc9WFjn2c", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "卓泽", + "first_shared": "2026-05-13 22:15:01", + "group": "创新组", + "context": "[]()", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/U32FwRkZPiYu9vkEtXPcRNVVnSe", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-13 02:14:15", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/IGr9wUHPUi6dMwkE1s6cVKPfnGe", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "韦译", + "first_shared": "2026-05-12 22:48:57", + "group": "创新组", + "context": "今天解决的一个问题:在claude code中接入ak和sk形式的api", + "share_count": 1 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/ZKeNw6V9ViwCH3kyAM9cOYSpntf", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "卓泽", + "first_shared": "2026-05-12 22:48:29", + "group": "创新组", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/NkY6wVzfliQAyykiWsEcaN9cnue", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "韦译", + "first_shared": "2026-05-12 22:47:25", + "group": "创新组", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/F8jiwgDmkiyzLMk5KYecuOjinAg", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-12 00:22:24", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/YmolwbdlOikKWMkGgQmcTflMnQe", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "卓泽", + "first_shared": "2026-05-11 20:06:34", + "group": "创新组", + "context": "url:", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/RdWtwxGwPi4DRzkhpOEc6S84nsf", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "卓泽", + "first_shared": "2026-05-10 11:34:30", + "group": "创新组", + "context": "[分享] Docs url:", + "share_count": 3 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/EpZZw1rT9iBZDFkrwo2cgImpngb", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-10 03:02:35", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/CHZiwHehNizCJKkhZqccilaknMd", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "卓泽", + "first_shared": "2026-05-09 06:29:32", + "group": "创新组", + "context": "[分享] Docs url:", + "share_count": 3 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/NzSOwDHlgiPCx9klcKWcxzawnhe", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-09 01:33:11", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/KRxGwTZ0miRVMMk0fjPcIVv7nge", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-08 01:50:47", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/NjkVwE5b2iG9wbksmy5ciSqDnDp", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "卓泽", + "first_shared": "2026-05-07 22:56:48", + "group": "创新组", + "context": "本日日报: \n还有昨天的改了下: https://dianchukeji.feishu.cn/wiki/GQnLwK4cmiqCVpkFieVcF6JmnGd", + "share_count": 1 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/GQnLwK4cmiqCVpkFieVcF6JmnGd", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "卓泽", + "first_shared": "2026-05-07 22:56:48", + "group": "创新组", + "context": "本日日报: https://dianchukeji.feishu.cn/wiki/NjkVwE5b2iG9wbksmy5ciSqDnDp\n还有昨天的改了下:", + "share_count": 1 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/FFY7wfiFaig3pMkg9H7cFobFn7g", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-07 01:07:15", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + }, + { + "url": "https://my.feishu.cn/wiki/LSY7we2ceiJ5s5kOJwoclB77nXc", + "type": "wiki", + "domain": "my.feishu.cn (个人飞书)", + "shared_by": "卓泽", + "first_shared": "2026-05-06 21:58:20", + "group": "创新组", + "context": "本日日报:", + "share_count": 1 + }, + { + "url": "https://dianchukeji.feishu.cn/wiki/Gh8cw3QnJiplq1k2lmFcajidnHl", + "type": "wiki", + "domain": "dianchukeji (公司飞书)", + "shared_by": "王雨默", + "first_shared": "2026-05-01 02:38:52", + "group": "创新组", + "context": "?from=from_copylink url: ?from=from_copylink", + "share_count": 2 + } + ], + "files": [ + { + "name": "游戏行业核心观点梳理.pdf", + "fileId": "b9Y4gmKWrPNm30nEFjoRXP4aJGXn6lpz", + "sender": "李志健", + "time": "2026-05-15 10:28:47", + "group": "dc战略问题研究院" + }, + { + "name": "AI视频创作作品分享罗剑豪V3.pptx", + "fileId": "yQod3RxJKGDndA07i4noekLyJkb4Mw9r", + "sender": "李志健", + "time": "2026-05-13 14:36:23", + "group": "dc战略问题研究院" + }, + { + "name": "坦克大逃杀答辩材料:从代码搬运工到架构师助理.pptx", + "fileId": "QBnd5ExVEvEp5KZ2I2pgG5ElJyeZqMmz", + "sender": "李志健", + "time": "2026-05-13 14:36:02", + "group": "dc战略问题研究院" + }, + { + "name": "《仙途乐逍遥》AI歌曲分享文档.xmind", + "fileId": "R4GpnMqJzGmy3dxEiaZkMN5R8Ke0xjE3", + "sender": "李志健", + "time": "2026-05-13 14:35:35", + "group": "dc战略问题研究院" + }, + { + "name": "刘亚彬-万剑囚天镇压獓因-分享文档02.pptx", + "fileId": "DnRL6jAJMGMRdeY0iXRqqAa6WyMoPYe1", + "sender": "李志健", + "time": "2026-05-13 14:34:08", + "group": "dc战略问题研究院" + }, + { + "name": "寻仇AI视频制作分享PPT (2).pptx", + "fileId": "0eMKjyp813zlbnexs4j4XpbgVxAZB1Gv", + "sender": "李志健", + "time": "2026-05-13 14:21:13", + "group": "dc战略问题研究院" + }, + { + "name": "模型报告.html", + "fileId": "MyQA2dXW7eRdPjKxS5AA5P41JzlwrZgb", + "sender": "李志健", + "time": "2026-05-11 01:28:58", + "group": "dc战略问题研究院" + }, + { + "name": "game-analyst-agent.zip", + "fileId": "mweZ92PV6M7e1qQxSKmpwOq0WxEKBD6p", + "sender": "黄静雯", + "time": "2026-05-22 09:02:50", + "group": "dc战略问题研究院" + }, + { + "name": "game-analyst-agent-manual.html", + "fileId": "QPGYqjpJYr7lQGAXFZRQ6lnM8akx1Z5N", + "sender": "黄静雯", + "time": "2026-05-22 09:02:50", + "group": "dc战略问题研究院" + }, + { + "name": "2026-05-yunhu-project-selection-strategy-report.html", + "fileId": "4lgGw3P8vR203ZrEHpG2gyYE85daZ90D", + "sender": "黄静雯", + "time": "2026-05-21 00:35:28", + "group": "dc战略问题研究院" + }, + { + "name": "取败之道——关于幸存者偏差、筹码管理与生长逻辑的深度反思.md", + "fileId": "0eMKjyp813zlbnexs4d9bqrZVxAZB1Gv", + "sender": "李志健", + "time": "2026-05-20 10:22:27", + "group": "dc战略问题研究院" + }, + { + "name": "花园世界产品策略_GOS补充信息.md", + "fileId": "NkDwLng8ZLRBbjGpCxxqXz1MVKMEvZBY", + "sender": "傅明游", + "time": "2026-05-26 16:00:45", + "group": "dc战略问题研究院" + }, + { + "name": "2026-05-25_report_my_garden_world_us_project.html", + "fileId": "wva2dxOW4YmAb01xF0BnvLNEVbkz3BRL", + "sender": "黄静雯", + "time": "2026-05-26 09:29:12", + "group": "dc战略问题研究院" + }, + { + "name": "主报告-我的花园世界.html", + "fileId": "y20BglGWO2NbdYyKt0peOkjl8A7depqY", + "sender": "李志健", + "time": "2026-06-01 23:36:40", + "group": "dc战略问题研究院" + }, + { + "name": "进一步的思考.md", + "fileId": "QPGYqjpJYr7lQGAXFZ0njADy8akx1Z5N", + "sender": "李志健", + "time": "2026-06-01 23:09:45", + "group": "dc战略问题研究院" + }, + { + "name": "花园项目对策划的启示.md", + "fileId": "7QG4Yx2JpLMZmdaECglLlO2aJ9dEq3XD", + "sender": "李志健", + "time": "2026-06-01 22:55:36", + "group": "dc战略问题研究院" + }, + { + "name": "花园世界等相关产品25.10.28.xlsx", + "fileId": "QPGYqjpJYr7lQGAXFZ0beYjZ8akx1Z5N", + "sender": "李志健", + "time": "2026-06-01 21:42:33", + "group": "dc战略问题研究院" + }, + { + "name": "工作流总结-王雨默.html", + "fileId": "1zknDm0WRamRxP60IxnN2Dwk8BQEx5rG", + "sender": "王雨默", + "time": "2026-05-22 10:57:31", + "group": "创新组" + } + ], + "topics": [ + { + "name": "《我的花园世界》深度研究", + "description": "围绕《我的花园世界》的全方位研究,包括产品机制、商业化、资源经济、竞品对比", + "key_people": [ + "李志健", + "黄静雯", + "陈楚真", + "傅明游" + ], + "documents_count": 0, + "files": [ + "主报告-我的花园世界.html", + "2026-05-25_report_my_garden_world_us_project.html", + "花园项目对策划的启示.md", + "进一步的思考.md", + "花园世界产品策略_GOS补充信息.md", + "花园世界等相关产品25.10.28.xlsx" + ], + "key_concepts": [ + "低压经营", + "极致消耗", + "非战斗GVG", + "社交拉氪", + "大通服", + "腰部底座放大" + ] + }, + { + "name": "云湖工作室项目选择", + "description": "广州云湖工作室第一个转型项目的方向选择分析", + "key_people": [ + "黄静雯" + ], + "documents_count": 0, + "files": [ + "2026-05-yunhu-project-selection-strategy-report.html" + ], + "key_concepts": [ + "2个月MVP", + "AI美术适配", + "素材CPI验证", + "欧美化花园经营" + ] + }, + { + "name": "Game Analyst Agent 工具", + "description": "通用产品分析自动化工具,自动探索游戏界面、提取机制与数值", + "key_people": [ + "黄静雯" + ], + "documents_count": 0, + "files": [ + "game-analyst-agent-manual.html", + "game-analyst-agent.zip" + ], + "key_concepts": [ + "自动界面探索", + "pHash去重", + "9级决策链", + "多游戏对比", + "决策报告生成" + ] + }, + { + "name": "战略思维与方法论", + "description": "李志健关于幸存者偏差、筹码管理、生长逻辑的战略反思", + "key_people": [ + "李志健" + ], + "documents_count": 0, + "files": [ + "取败之道.md", + "模型报告.html" + ], + "key_concepts": [ + "幸存者偏差", + "筹码管理", + "正期望博弈", + "生长逻辑", + "非对称博弈" + ] + }, + { + "name": "AI落地与组织变革", + "description": "AI在游戏研发中的实际落地、效率提升与组织变革讨论", + "key_people": [ + "李志健", + "林峰", + "汪雄军", + "上官成", + "安东" + ], + "documents_count": 0, + "files": [], + "key_concepts": [ + "AI军备竞赛", + "端到端提效", + "组织变革", + "AI工作小组" + ] + }, + { + "name": "创新组日报与研发进展", + "description": "创新组成员的每日工作日报,涵盖二合类游戏研发、AI工具使用", + "key_people": [ + "王雨默", + "韦译", + "刘鹏", + "卓泽", + "徐锐" + ], + "documents_count": 0, + "files": [ + "工作流总结-王雨默.html" + ], + "key_concepts": [ + "二合类游戏", + "AI关卡生成", + "UI编辑器", + "数值平衡", + "竞品分析" + ] + }, + { + "name": "战略组日报与知识产出", + "description": "战略研究组成员每日提交的研究日报", + "key_people": [ + "黄静雯", + "陈楚真", + "张家振", + "夏莲", + "莫润麟", + "胡辉俊", + "汪季" + ], + "documents_count": 0, + "files": [], + "key_concepts": [ + "竞品拆解", + "知识卡片", + "MECH/REPORT/ORG卡片", + "Agent架构" + ] + } + ], + "relationships": [ + { + "source": "李志健", + "target": "《我的花园世界》深度研究", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "黄静雯", + "target": "《我的花园世界》深度研究", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "陈楚真", + "target": "《我的花园世界》深度研究", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "傅明游", + "target": "《我的花园世界》深度研究", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "黄静雯", + "target": "云湖工作室项目选择", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "黄静雯", + "target": "Game Analyst Agent 工具", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "李志健", + "target": "战略思维与方法论", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "李志健", + "target": "AI落地与组织变革", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "林峰", + "target": "AI落地与组织变革", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "汪雄军", + "target": "AI落地与组织变革", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "上官成", + "target": "AI落地与组织变革", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "安东", + "target": "AI落地与组织变革", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "王雨默", + "target": "创新组日报与研发进展", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "韦译", + "target": "创新组日报与研发进展", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "刘鹏", + "target": "创新组日报与研发进展", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "卓泽", + "target": "创新组日报与研发进展", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "徐锐", + "target": "创新组日报与研发进展", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "黄静雯", + "target": "战略组日报与知识产出", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "陈楚真", + "target": "战略组日报与知识产出", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "张家振", + "target": "战略组日报与知识产出", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "夏莲", + "target": "战略组日报与知识产出", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "莫润麟", + "target": "战略组日报与知识产出", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "胡辉俊", + "target": "战略组日报与知识产出", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "汪季", + "target": "战略组日报与知识产出", + "type": "contributes_to", + "weight": 1 + }, + { + "source": "林祥武", + "target": "汪雄军", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林祥武", + "target": "陈楚真", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林祥武", + "target": "汪季", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林祥武", + "target": "莫润麟", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林祥武", + "target": "胡辉俊", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林祥武", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林祥武", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林祥武", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林祥武", + "target": "路弘阁", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "林祥武", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "汪雄军", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "张家振", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "陈楚真", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "曹纲玮", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "安东", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "林云龙", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "文健", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "汪季", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "夏莲", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "傅明游", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "吴爽", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "莫润麟", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "胡辉俊", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "彭俊豪", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "李志健", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "路弘阁", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "上官成", + "target": "林峰", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "汪雄军", + "target": "陈楚真", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "汪雄军", + "target": "莫润麟", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "汪雄军", + "target": "胡辉俊", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "汪雄军", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "汪雄军", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "汪雄军", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "汪雄军", + "target": "路弘阁", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "张家振", + "target": "林祥武", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "张家振", + "target": "汪雄军", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "张家振", + "target": "陈楚真", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "张家振", + "target": "曹纲玮", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "张家振", + "target": "林云龙", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "张家振", + "target": "文健", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "张家振", + "target": "汪季", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "张家振", + "target": "莫润麟", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "张家振", + "target": "胡辉俊", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "张家振", + "target": "彭俊豪", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "张家振", + "target": "李志健", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "张家振", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "张家振", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "张家振", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "张家振", + "target": "路弘阁", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "张家振", + "target": "林峰", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "陈楚真", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "陈楚真", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "陈楚真", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "曹纲玮", + "target": "林祥武", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "曹纲玮", + "target": "汪雄军", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "曹纲玮", + "target": "陈楚真", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "曹纲玮", + "target": "林云龙", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "曹纲玮", + "target": "汪季", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "曹纲玮", + "target": "莫润麟", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "曹纲玮", + "target": "胡辉俊", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "曹纲玮", + "target": "李志健", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "曹纲玮", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "曹纲玮", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "曹纲玮", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "曹纲玮", + "target": "路弘阁", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "曹纲玮", + "target": "林峰", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "安东", + "target": "林祥武", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "安东", + "target": "汪雄军", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "安东", + "target": "张家振", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "安东", + "target": "陈楚真", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "安东", + "target": "曹纲玮", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "安东", + "target": "林云龙", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "安东", + "target": "文健", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "安东", + "target": "汪季", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "安东", + "target": "莫润麟", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "安东", + "target": "胡辉俊", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "安东", + "target": "彭俊豪", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "安东", + "target": "李志健", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "安东", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "安东", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "安东", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "安东", + "target": "路弘阁", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "安东", + "target": "林峰", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林云龙", + "target": "林祥武", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林云龙", + "target": "汪雄军", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林云龙", + "target": "陈楚真", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林云龙", + "target": "汪季", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林云龙", + "target": "莫润麟", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林云龙", + "target": "胡辉俊", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林云龙", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林云龙", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林云龙", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林云龙", + "target": "路弘阁", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林云龙", + "target": "林峰", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "文健", + "target": "林祥武", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "文健", + "target": "汪雄军", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "文健", + "target": "陈楚真", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "文健", + "target": "曹纲玮", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "文健", + "target": "林云龙", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "文健", + "target": "汪季", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "文健", + "target": "莫润麟", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "文健", + "target": "胡辉俊", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "文健", + "target": "李志健", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "文健", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "文健", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "文健", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "文健", + "target": "路弘阁", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "文健", + "target": "林峰", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "汪季", + "target": "汪雄军", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "汪季", + "target": "陈楚真", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "汪季", + "target": "莫润麟", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "汪季", + "target": "胡辉俊", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "汪季", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "汪季", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "汪季", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "汪季", + "target": "路弘阁", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "夏莲", + "target": "林祥武", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "夏莲", + "target": "汪雄军", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "夏莲", + "target": "张家振", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "夏莲", + "target": "陈楚真", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "夏莲", + "target": "曹纲玮", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "夏莲", + "target": "安东", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "夏莲", + "target": "林云龙", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "夏莲", + "target": "文健", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "夏莲", + "target": "汪季", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "夏莲", + "target": "莫润麟", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "夏莲", + "target": "胡辉俊", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "夏莲", + "target": "彭俊豪", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "夏莲", + "target": "李志健", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "夏莲", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "夏莲", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "夏莲", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "夏莲", + "target": "路弘阁", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "夏莲", + "target": "林峰", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "林祥武", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "汪雄军", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "张家振", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "陈楚真", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "曹纲玮", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "安东", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "林云龙", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "文健", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "汪季", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "夏莲", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "吴爽", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "莫润麟", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "胡辉俊", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "彭俊豪", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "李志健", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "路弘阁", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "傅明游", + "target": "林峰", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "林祥武", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "汪雄军", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "张家振", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "陈楚真", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "曹纲玮", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "安东", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "林云龙", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "文健", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "汪季", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "夏莲", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "莫润麟", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "胡辉俊", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "彭俊豪", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "李志健", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "路弘阁", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "吴爽", + "target": "林峰", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "莫润麟", + "target": "陈楚真", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "莫润麟", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "莫润麟", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "莫润麟", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "莫润麟", + "target": "路弘阁", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "胡辉俊", + "target": "陈楚真", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "胡辉俊", + "target": "莫润麟", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "胡辉俊", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "胡辉俊", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "胡辉俊", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "胡辉俊", + "target": "路弘阁", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "彭俊豪", + "target": "林祥武", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "彭俊豪", + "target": "汪雄军", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "彭俊豪", + "target": "陈楚真", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "彭俊豪", + "target": "曹纲玮", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "彭俊豪", + "target": "林云龙", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "彭俊豪", + "target": "文健", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "彭俊豪", + "target": "汪季", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "彭俊豪", + "target": "莫润麟", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "彭俊豪", + "target": "胡辉俊", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "彭俊豪", + "target": "李志健", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "彭俊豪", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "彭俊豪", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "彭俊豪", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "彭俊豪", + "target": "路弘阁", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "彭俊豪", + "target": "林峰", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "李志健", + "target": "林祥武", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "李志健", + "target": "汪雄军", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "李志健", + "target": "陈楚真", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "李志健", + "target": "林云龙", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "李志健", + "target": "汪季", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "李志健", + "target": "莫润麟", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "李志健", + "target": "胡辉俊", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "李志健", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "李志健", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "李志健", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "李志健", + "target": "路弘阁", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "李志健", + "target": "林峰", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "韩丹", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "韩丹", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "黄祥钦", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "路弘阁", + "target": "陈楚真", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "路弘阁", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "路弘阁", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "路弘阁", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林峰", + "target": "林祥武", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林峰", + "target": "汪雄军", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林峰", + "target": "陈楚真", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林峰", + "target": "汪季", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林峰", + "target": "莫润麟", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林峰", + "target": "胡辉俊", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林峰", + "target": "韩丹", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林峰", + "target": "黄静雯", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林峰", + "target": "黄祥钦", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "林峰", + "target": "路弘阁", + "type": "co_group_member", + "group": "dc战略问题研究院", + "weight": 1 + }, + { + "source": "李志健", + "target": "韦译", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "李志健", + "target": "黄静雯", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "李志健", + "target": "王雨默", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "韦译", + "target": "黄静雯", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "刘鹏", + "target": "李志健", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "刘鹏", + "target": "韦译", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "刘鹏", + "target": "黄静雯", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "刘鹏", + "target": "安东", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "刘鹏", + "target": "徐锐", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "刘鹏", + "target": "卓泽", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "刘鹏", + "target": "王雨默", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "上官成", + "target": "李志健", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "上官成", + "target": "韦译", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "上官成", + "target": "刘鹏", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "上官成", + "target": "黄静雯", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "上官成", + "target": "安东", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "上官成", + "target": "徐锐", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "上官成", + "target": "卓泽", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "上官成", + "target": "王雨默", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "安东", + "target": "李志健", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "安东", + "target": "韦译", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "安东", + "target": "黄静雯", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "安东", + "target": "徐锐", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "安东", + "target": "王雨默", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "徐锐", + "target": "李志健", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "徐锐", + "target": "韦译", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "徐锐", + "target": "黄静雯", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "徐锐", + "target": "王雨默", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "卓泽", + "target": "李志健", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "卓泽", + "target": "韦译", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "卓泽", + "target": "黄静雯", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "卓泽", + "target": "安东", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "卓泽", + "target": "徐锐", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "卓泽", + "target": "王雨默", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "AI小钉", + "target": "李志健", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "AI小钉", + "target": "韦译", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "AI小钉", + "target": "刘鹏", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "AI小钉", + "target": "上官成", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "AI小钉", + "target": "黄静雯", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "AI小钉", + "target": "安东", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "AI小钉", + "target": "徐锐", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "AI小钉", + "target": "卓泽", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "AI小钉", + "target": "王雨默", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "王雨默", + "target": "韦译", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + }, + { + "source": "王雨默", + "target": "黄静雯", + "type": "co_group_member", + "group": "创新组", + "weight": 1 + } + ] +} \ No newline at end of file diff --git a/output/knowledge-graph/knowledge_graph_mermaid.md b/output/knowledge-graph/knowledge_graph_mermaid.md new file mode 100644 index 0000000..74d4151 --- /dev/null +++ b/output/knowledge-graph/knowledge_graph_mermaid.md @@ -0,0 +1,97 @@ +# 知识图谱 - dc战略问题研究院 & 创新组 + +```mermaid +graph TB + + classDef person fill:#4A90D9,stroke:#2C5F8A,color:#fff,stroke-width:2px + classDef topic fill:#E8A838,stroke:#B8842C,color:#fff,stroke-width:2px + classDef doc fill:#5CB85C,stroke:#3D8B3D,color:#fff,stroke-width:1px + classDef file fill:#D9534F,stroke:#B94441,color:#fff,stroke-width:1px + classDef group fill:#9B59B6,stroke:#7D3C98,color:#fff,stroke-width:2px + + subgraph G1[dc战略问题研究院] + li_zj[李志健]:::person + huang_jw[黄静雯]:::person + chen_cz[陈楚真]:::person + fu_my[傅明游]:::person + xia_l[夏莲]:::person + zhang_jz[张家振]:::person + mo_rl[莫润麟]:::person + hu_hj[胡辉俊]:::person + wang_j[汪季]:::person + end + + subgraph G2[创新组] + wang_ym[王雨默]:::person + wei_y[韦译]:::person + liu_p[刘鹏]:::person + zhuo_z[卓泽]:::person + xu_r[徐锐]:::person + end + + subgraph G3[跨组人员] + shangguan_c[上官成]:::person + an_d[安东]:::person + lin_f[林峰]:::person + end + + subgraph T[核心研究主题] + t1[花园世界深度研究]:::topic + t2[云湖项目选择]:::topic + t3[Game Analyst Agent]:::topic + t4[战略思维方法论]:::topic + t5[AI落地与组织变革]:::topic + t6[创新组研发]:::topic + t7[战略组知识产出]:::topic + end + + subgraph F[关键文件] + f1[主报告-我的花园世界.html]:::file + f2[美国版策略报告.html]:::file + f3[云湖项目选择.html]:::file + f4[game-analyst-agent.html]:::file + f5[取败之道.md]:::file + f6[策划启示.md]:::file + f7[进一步的思考.md]:::file + f8[GOS补充信息.md]:::file + end + + %% Person -> Topic + li_zj --> t1 + li_zj --> t4 + li_zj --> t5 + huang_jw --> t1 + huang_jw --> t2 + huang_jw --> t3 + huang_jw --> t7 + chen_cz --> t1 + chen_cz --> t7 + fu_my --> t1 + wang_ym --> t6 + wei_y --> t6 + liu_p --> t6 + shangguan_c --> t5 + lin_f --> t5 + + %% Topic -> Files + t1 --> f1 + t1 --> f2 + t1 --> f6 + t1 --> f7 + t1 --> f8 + t2 --> f3 + t3 --> f4 + t4 --> f5 + + %% Daily report flow (研究组) + xia_l -.->|daily report| t7 + zhang_jz -.->|daily report| t7 + mo_rl -.->|daily report| t7 + hu_hj -.->|daily report| t7 + wang_j -.->|daily report| t7 + + %% Cross-group + huang_jw -.->|跨组| t6 + li_zj -.->|指导| t6 + li_zj -.->|指导| t7 +``` diff --git a/output/obsidian-vault/00-MOC/战略研究体系.md b/output/obsidian-vault/00-MOC/战略研究体系.md new file mode 100644 index 0000000..bc5738c --- /dev/null +++ b/output/obsidian-vault/00-MOC/战略研究体系.md @@ -0,0 +1,45 @@ +--- +tags: [MOC, 战略, 方法论] +created: 2026-06-02 +--- + +# 战略研究体系 + +> dc战略问题研究院的研究方法论和思维框架 + +## 核心思维框架 + +- [[取败之道-战略反思]] — 李志健的战略反思:幸存者偏差、筹码管理、生长逻辑 +- [[腰部底座识别方法]] — 从腰部产品中发现放大机会 +- [[立项评估框架]] — 6问检查清单 + +## 研究方法 + +### 腰部产品研究路径 +``` +腰部产品发现 → 潜力验证 → 机制迁移 → 力量放大 +``` + +### 识别标准 +1. 核心循环已被用户验证(留存/付费成立) +2. 美术、传播、商业化、运营至少有一层没做透 +3. 我方能在至少一项上形成代差 +4. 短板是"能力问题"而非"结构问题" + +### 信息源分级 +- ✅ 多源一致 — 可直接引用 +- ⚠️ 单源或口径存疑 — 待核 +- ⛏️ 需游戏内实测复核 + +## 工具支持 + +- [[Game-Analyst-Agent工具]] — 自动化竞品分析 +- 黄静雯的[[飞书MCP Server]] — 自动知识提取 +- 知识卡片系统(MECH/REPORT/ORG卡片) + +## 关键人物 + +- [[李志健]] — 战略方向制定者 +- [[黄静雯]] — 研究执行主力,工具建设 +- [[陈楚真]] — 商业化深度研究 +- [[傅明游]] — GOS侧实测数据 diff --git a/output/obsidian-vault/00-MOC/花园世界研究总览.md b/output/obsidian-vault/00-MOC/花园世界研究总览.md new file mode 100644 index 0000000..7ff1e98 --- /dev/null +++ b/output/obsidian-vault/00-MOC/花园世界研究总览.md @@ -0,0 +1,84 @@ +--- +tags: [MOC, 花园世界, 战略研究] +created: 2026-06-02 +--- + +# 花园世界研究总览 + +> dc战略问题研究院 + 创新组 围绕《我的花园世界》的全量研究成果索引 + +## 研究结论(先看这里) + +**一句话结论**:不要学"种花题材",要学"已验证底座 + 放大能力"的立项路径。 + +**五条战略启发**: +1. 立项找已被验证但没被充分放大的[[腰部底座识别方法|腰部底座]] +2. 做[[非战斗GVG设计参数|异步、低压、人人有贡献的非战斗GVG]] +3. 设计[[社交拉氪模型|"被需要"的社交付费理由]] +4. 规划[[花园世界-商业化分析|长短周期错频运营]] +5. 把履约/客服当产品能力,不是福利 + +**核心公式**: +> 商业成功 = 已验证底座 × [[花园世界-增长飞轮|放大能力]](美术 + 营销 + 商业化 + 运营) + +--- + +## 产品研究 + +- [[我的花园世界-产品画像]] — 厂商、数据、品类定位 +- [[花园世界-底座溯源]] — 天苻科技的品类验证史 +- [[花园世界-四层产品结构]] — 低压经营 → 收集 → GVG → 消耗 +- [[花园世界-极致消耗模型]] — 为什么玩家永远缺资源 +- [[花园世界-非战斗GVG]] — 不打架的公会竞赛怎么成立 +- [[花园世界-社交拉氪模型]] — 氪金 = 被需要 +- [[花园世界-商业化分析]] — 购物感 + 社会地位价值 +- [[花园世界-增长飞轮]] — 种虚拟花收真实花 +- [[花园世界-美国版策略]] — 美国版复刻的六面承重墙 +- [[花园世界-GOS补充数据]] — GOS侧实测反馈 + +## 方法论 + +- [[取败之道-战略反思]] — 幸存者偏差与筹码管理 +- [[腰部底座识别方法]] — 如何找到可被放大的产品 +- [[非战斗GVG设计参数]] — 设计参数表 +- [[立项评估框架]] — 6问检查清单 +- [[AI落地与组织变革]] — AI军备竞赛的紧迫性 + +## 项目落地 + +- [[云湖工作室项目选择]] — 16人团队2个月MVP方案 +- [[花园世界-MVP验证方案]] — 3个月验证路径 +- [[Game-Analyst-Agent工具]] — 自动化竞品分析工具 + +## 行业趋势 + +- [[休闲入口嫁接中重度运营]] — Gossip Harbor等案例 +- [[AI军备竞赛]] — 行业洗牌加速 + +## 数据索引 + +- [[花园世界核心数据]] — 全部可量化数据 +- [[研究组日报索引]] — 7人53篇日报链接 +- [[人物图谱]] — 28位活跃人员 + +## 外部研究链接 + +| 标题 | 作者 | 链接 | +|------|------|------| +| 商业化梳理报告 | [[陈楚真]] | https://kblb6hdbtbfto.ok.kimi.link/ | +| 资源经济深度研究 | [[陈楚真]] | https://upy4l3m3qnegc.ok.kimi.link/ | +| 限时活动专题 | [[陈楚真]] | https://upy4l3m3qnegc.ok.kimi.link/#/activity-study | +| 长期更新运营专题 | [[陈楚真]] | https://upy4l3m3qnegc.ok.kimi.link/#/long-term-study | + +## 原始文件 + +已下载到 `dc_html_md/` 目录: +- 主报告-我的花园世界.html (90KB, [[李志健]]) +- 2026-05-25_report_my_garden_world_us_project.html (46KB, [[黄静雯]]) +- 2026-05-yunhu-project-selection-strategy-report.html (40KB, [[黄静雯]]) +- game-analyst-agent-manual.html (49KB, [[黄静雯]]) +- 取败之道.md (15KB, [[李志健]]) +- 进一步的思考.md (8.4KB, [[李志健]]) +- 花园项目对策划的启示.md (5.4KB, [[李志健]]) +- 花园世界产品策略_GOS补充信息.md (2.7KB, [[傅明游]]) +- 花园世界等相关产品25.10.28.xlsx (452KB, [[李志健]]) diff --git a/output/obsidian-vault/01-产品研究/我的花园世界-产品画像.md b/output/obsidian-vault/01-产品研究/我的花园世界-产品画像.md new file mode 100644 index 0000000..b6131a2 --- /dev/null +++ b/output/obsidian-vault/01-产品研究/我的花园世界-产品画像.md @@ -0,0 +1,50 @@ +--- +tags: [产品研究, 花园世界, 女性向, 休闲经营] +created: 2026-06-02 +source: 主报告-我的花园世界.html +confidence: ✅ 多源一致 +--- + +# 我的花园世界 — 产品画像 + +> 返回 [[花园世界研究总览]] + +## 基本信息 + +| 字段 | 内容 | +|------|------| +| 产品名 | 《我的花园世界》/ My Garden Tale | +| 研发商 | 厦门麟贝互娱(com.jxhy.official) | +| 海外发行 | 厦门摩多科技(Modo Game / MODO PTE. LTD.) | +| 国内出版 | 浙江出版集团数字传媒有限公司 | +| 上线时间 | 2025-08-05(国内公测),9月微信小游戏 | +| 品类 | 女性向休闲经营养成 | +| 美术风格 | 仿唐国风、治愈系 | +| 目标用户 | 25-45岁女性,宝妈,休闲小游戏用户 | + +## 核心数据 + +| 指标 | 数据 | 可信度 | +|------|------|--------| +| 峰值DAU | 千万级 | ✅ | +| 峰值月流水 | 预估4-5亿元 | ⚠️ 推算 | +| iOS免费榜 | 霸榜约2周 | ✅ | +| iOS畅销榜 | 前5 | ✅ | +| Google Play | 100万+下载,4.5分 | ✅ | +| 美国App Store | 4.7分 | ✅ | +| TapTap | 7.8分,~30万下载 | ✅ | +| 海外iOS下载 | 美国Top 4 | ✅ | + +## 关键认知 + +**底座验证者与放大者是两家不同公司**: +- 深圳天苻科技验证了品类底座([[花园世界-底座溯源]]) +- 厦门麟贝互娱把它放大成现象级产品 +- 这意味着这类机会对任何有放大能力的公司都是开放的 + +## 相关链接 + +- [[花园世界-四层产品结构]] +- [[花园世界-商业化分析]] +- [[花园世界-增长飞轮]] +- [[花园世界核心数据]] diff --git a/output/obsidian-vault/01-产品研究/花园世界-GOS补充数据.md b/output/obsidian-vault/01-产品研究/花园世界-GOS补充数据.md new file mode 100644 index 0000000..bda2f02 --- /dev/null +++ b/output/obsidian-vault/01-产品研究/花园世界-GOS补充数据.md @@ -0,0 +1,49 @@ +--- +tags: [产品研究, 花园世界, GOS, 实测数据] +created: 2026-06-02 +source: 花园世界产品策略_GOS补充信息.md +author: [[傅明游]] +confidence: ✅ 已验证数据 + ⚠️ 内部猜测 +--- + +# 花园世界 — GOS补充数据 + +> 返回 [[花园世界研究总览]] + +## 已验证数据 + +### 用户画像重合 +- GOS的美国用户群体与花园世界的用户属性有较高重合度 +- GOS已验证30+女性玩家"**合作>竞争、低压>高压**"的诉求 + +### 买量测试 +- GOS简单尝试过种花类买量素材 → 点击率和获客成本**无明显优势** +- 说明:不是简单复刻花园素材就能获量,需要深度研判和测试 + +### 低压力循环复刻 +- GOS以半个月活动周期复刻花园世界低压力循环+无限数值消耗原型(无GVE和深度社交) +- 结果:**营收和口碑高于常规活动** + +### GVE独立测试 +- GOS将花园世界GVE拆分为独立活动 +- 预计7月周年庆上线,可独立观察GVE层效果 + +## 中重度融合探索 + +- GOS融合休闲玩法,GOK融合SLG +- 双方均感受到玩家诉求存在**强差异化和基础矛盾** +- GOS女性用户对超休闲策略小游戏接受度较高 + +## GOK/VK的补充(傅明游) + +- GOK和VK偏SLG,模型能做到**1.5~2倍LTV差异** +- 无尽冬日接入SLG是"**质的变化**"(生命周期和模型变化) +- GOS商业化运营是"**量的变化**"(在已有模型里拔高) + +## 内部猜测(待验证) + +1. **吸量**:核心吸量可能通过送真花类素材实现,其余素材无特殊优势 +2. **需求缺口**:主要抓住女性向用户需求缺口,如果缺口正在被快速填补,正面竞争难度大 +3. **中后期**:可能面临内容填充问题,商业化结构有迭代空间 + +相关:[[花园世界-商业化分析]]、[[花园世界-增长飞轮]] diff --git a/output/obsidian-vault/01-产品研究/花园世界-商业化分析.md b/output/obsidian-vault/01-产品研究/花园世界-商业化分析.md new file mode 100644 index 0000000..d2c720f --- /dev/null +++ b/output/obsidian-vault/01-产品研究/花园世界-商业化分析.md @@ -0,0 +1,53 @@ +--- +tags: [产品研究, 花园世界, 商业化, 运营] +created: 2026-06-02 +--- + +# 花园世界 — 商业化分析 + +> 返回 [[花园世界研究总览]] + +## 商业化哲学 + +**弱化卡点逼氪、叠加社交责任型付费**。传统逼氪元素仍存在,但核心创新在于社交拉氪。详见:[[花园世界-社交拉氪模型]] + +## 9大活动体系 + +### 四大活动(长周期) +提供长期目标和高价值奖励 + +### 五小活动(短周期) +提供变化感和轻玩法 + +### 节日/联动层 +负责回流与传播 + +## 双层错频运营骨架 + +``` +长周期活动(1-2周):提供目标感 +短周期活动(3-4天):提供变化感 +节日/联动活动:负责回流 +公会周期:负责组织目标 +日常任务:负责稳定登录 +``` + +**关键**:不要所有活动都抢同一时间、同一资源、同一入口。 + +## 用户分层 + +| 层级 | 付费行为 | 系统角色 | +|------|----------|----------| +| 免费玩家 | 不付费 | 提供基础贡献、社交生态基础 | +| 微氪 | 月卡/小额 | 加速体验、轻度贡献 | +| 中R | 礼包/活动 | 公会竞赛中坚力量 | +| 大R | 周花/限定 | 拉高公会上限、社交展示 | + +## GOS侧实测反馈([[傅明游]]补充) + +- GOS复刻花园世界低压力循环原型 → **营收和口碑高于常规活动** +- GOS将GVE拆分为独立活动 → 预计7月周年庆上线 +- GOK/VK偏SLG,模型能做到**1.5~2倍LTV差异** +- 花园世界核心吸量可能通过送真花类素材实现 + +相关:[[花园世界-社交拉氪模型]]、[[花园世界-极致消耗模型]]、[[花园世界-GOS补充数据]] diff --git a/output/obsidian-vault/01-产品研究/花园世界-四层产品结构.md b/output/obsidian-vault/01-产品研究/花园世界-四层产品结构.md new file mode 100644 index 0000000..4dad1ae --- /dev/null +++ b/output/obsidian-vault/01-产品研究/花园世界-四层产品结构.md @@ -0,0 +1,54 @@ +--- +tags: [产品研究, 花园世界, 产品结构, 机制设计] +created: 2026-06-02 +--- + +# 花园世界 — 四层产品结构 + +> 返回 [[花园世界研究总览]] + +## 结构总览 + +``` +第一层:低压经营入口(种花、收花、订单、布置、收集) + ↓ 自然衔接 +第二层:横向收集和展示(花灵、限定花、装饰、称号) + ↓ 公会解锁 +第三层:公会异步任务型GVG(每周竞赛,有限次数) + ↓ 驱动 +第四层:极致消耗引擎(日常订单+活动+竞赛限时任务) +``` + +## 第一层:低压经营入口 +- 种花、收花、订单、布置、收集 +- 前期完成习惯养成,让经营变成日常条件反射 +- **不进公会也能形成完整循环** +- 碎片化时间切割:种植成熟压缩至极短,操作变成条件反射 +- 密集奖励:弹窗、经验跳动、物品掉落不断发送即时反馈 +- 零摩擦回归:几个月不玩状态完美保留 + +## 第二层:横向收集和展示 +- 花灵、限定花、装饰、称号 +- 让付费更接近**审美消费、收藏消费** +- 不是传统个人战力提升 + +## 第三层:公会异步任务型GVG +- "低协同、弱对抗、高覆盖、强分层、低焦虑" +- 异步任务制,每人有限次数,每周竞赛 +- 把个人经营转译为组织贡献 +- 详见:[[花园世界-非战斗GVG]] + +## 第四层:极致消耗引擎 +- 日常订单 + 活动任务 + 公会竞赛限时任务 +- 接近无限的订单持续消耗库存 +- 竞赛驱动图鉴扩展和当期付费 +- 详见:[[花园世界-极致消耗模型]] + +## 设计红线 + +1. 经营养成必须独立成立——不进公会也有完整体验 +2. 限定花不垄断高价值任务——不买当期新花也能做有意义贡献 +3. 错过无严重惩罚——不论什么时候继续都能正常体验 +4. 被公会踢的安全网默认做 + +相关:[[花园世界-社交拉氪模型]]、[[花园世界-商业化分析]] diff --git a/output/obsidian-vault/01-产品研究/花园世界-增长飞轮.md b/output/obsidian-vault/01-产品研究/花园世界-增长飞轮.md new file mode 100644 index 0000000..a42ce4c --- /dev/null +++ b/output/obsidian-vault/01-产品研究/花园世界-增长飞轮.md @@ -0,0 +1,54 @@ +--- +tags: [产品研究, 花园世界, 增长, 营销, 飞轮] +created: 2026-06-02 +--- + +# 花园世界 — 增长飞轮 + +> 返回 [[花园世界研究总览]] + +## 核心增长钩子 + +**"种虚拟花、收真实花束"** + +玩家晒的不是"游戏好玩",而是"我真的收到了花"。天然适合短视频与社交平台传播。 + +## 破圈三件套 + +1. **女频短剧素材** + 代言/话题 + 短视频买量产能 +2. **虚拟行为→现实社交货币**的获客钩子 +3. **微信群+游戏内社团**的双层玩家自治生态 + +## 增长漏斗 + +``` +触达(短视频/短剧素材/代言) + → 下载(真花承诺+轻松治愈定位) + → 首日体验(低压经营+密集奖励) + → 留存(日常习惯建立) + → 公会(资源需求驱动) + → 付费(社交拉氪+资源压力) + → 传播(晒花+社交分享) +``` + +## 风险面:增长资产可能反转为信任风险 + +- 真花兑现难、客服响应慢等投诉已出现 +- 如果掉率、兑换、配送、SLA不前置,增长钩子会反噬 +- **履约和客服必须当核心系统,不是运营附属** + +### 设计红线 +- 掉率和门槛是否透明 +- 兑换流程是否足够短 +- 配送范围和成本是否可控 +- 客服SLA是多少 +- 投诉、退款、补偿怎么处理 + +## 出海差异化 + +美国版应优先复刻机制结构,但必须验证: +- 题材画风吸量程度与购买欲 +- 付费动机与付费意愿 +- 社交路径与内容产能 + +相关:[[花园世界-美国版策略]]、[[休闲入口嫁接中重度运营]] diff --git a/output/obsidian-vault/01-产品研究/花园世界-底座溯源.md b/output/obsidian-vault/01-产品研究/花园世界-底座溯源.md new file mode 100644 index 0000000..3b3d4fa --- /dev/null +++ b/output/obsidian-vault/01-产品研究/花园世界-底座溯源.md @@ -0,0 +1,53 @@ +--- +tags: [产品研究, 花园世界, 底座溯源, 天苻科技] +created: 2026-06-02 +source: 主报告第三章 +--- + +# 花园世界 — 底座溯源 + +> 返回 [[花园世界研究总览]] + +## 天苻科技产品线迭代 + +### 鲜花小镇(2018,微信小游戏,至今运营) +首次验证底盘: +- 园艺社(15级开放) +- 社团竞赛体系(争霸赛+精英赛淘汰制+精确计分+明确付费路径) +- 抢夺花农、水滴瓶颈(2分钟/1滴、上限50) +- 混合变现 + +**关键发现**:早在2018年,社团竞赛就已相当深度。 + +### 秘密花园HD(2023) +系统化升级: +- 园艺社扩为六大模块(捐献/商店/种植/分享/竞赛/展馆) +- 社团竞赛改为黄金/钻石赛段轮换 +- 新增合约任务双轨通行证、异色花、花艺插花 +- 做饭/养娃/庭院/乙女恋爱副玩法矩阵 + +**但**:微信小游戏畅销榜最高约第40名,月收入仅百万级。 + +### 动物花店(2025-03) +继续加层:鲜花商会联盟与更开放的好友交易市场。 + +## 秘密花园HD为何不是爆款 + +它缺的不是底座,而是**放大能力**: +- 营销维度近乎空白 +- Q版古风美术在竞争中显古早 +- 乙女恋爱叙事私密、难做15秒短视频钩子 +- 商业化以IAP为主但深度不足 + +## 核心判断 + +> 系统完整 ≠ 商业成功。决定商业高度的不是系统清单,而是 **用户规模 × 付费深度 × 留存长度**。 + +## 底座识别四条标准 + +1. **已被验证**:核心循环已有留存/付费数据支撑 +2. **有放大空间**:美术/传播/商业化/运营至少一层没做透 +3. **我方有代差**:至少一项能力明显强于原产品 +4. **能力短板而非结构问题**:如果只是能力问题,有放大机会 + +相关:[[腰部底座识别方法]] diff --git a/output/obsidian-vault/01-产品研究/花园世界-极致消耗模型.md b/output/obsidian-vault/01-产品研究/花园世界-极致消耗模型.md new file mode 100644 index 0000000..494cd86 --- /dev/null +++ b/output/obsidian-vault/01-产品研究/花园世界-极致消耗模型.md @@ -0,0 +1,45 @@ +--- +tags: [产品研究, 花园世界, 消耗模型, 数值设计] +created: 2026-06-02 +--- + +# 花园世界 — 极致消耗模型 + +> 返回 [[花园世界研究总览]] + +## 核心设计 + +玩家长期处于**"有花但不够用"**的状态。日常订单/任务接近无上限。 + +## 消耗结构 + +| 消耗出口 | 消耗对象 | 压力人群 | 付费驱动 | +|----------|----------|----------|----------| +| 日常订单 | 花材库存 | 所有活跃玩家 | 时间加速+花材补充 | +| 公会竞赛-中低难度 | 花材库存(限时) | 平民/微氪 | 加速+库存补充 | +| 公会竞赛-高分任务 | 当期付费花 | 中高R | 周花礼包/限定花 | +| 活动/限定任务 | 特定花材+元宝 | 追求限定内容 | 活动礼包+加速 | +| 花灵/图鉴培育 | 培育材料+时间 | 收集型玩家 | 培育加速+材料 | + +## 关键设计:非累计式任务 + +主线和活动任务中存在大量**非累计式任务**: +- 历史积累不能减免当次消耗 +- 反复消耗同类资源 +- 库存管理成为核心能力——"有花"不等于"够用" +- 前期训练玩家从"完成任务"转向"管理资源" + +## 与Gossip Harbor对比 + +| 维度 | Gossip Harbor | 花园世界 | +|------|---------------|----------| +| 消耗瓶颈 | 时间/能量 | 库存品类 | +| 付费心理 | 即时冲动型 | **规划焦虑型** | +| 社交消耗层 | 无 | 公会竞赛+组团订单 | +| 无底洞形态 | 单层(个人速度) | **双层(日常库存+图鉴扩展)** | + +## 玩家生命周期 + +怀疑系统存在根据玩家库存动态推送订单的机制(C类推演,待验证)。 + +相关:[[花园世界-四层产品结构]]、[[花园世界-商业化分析]] diff --git a/output/obsidian-vault/01-产品研究/花园世界-社交拉氪模型.md b/output/obsidian-vault/01-产品研究/花园世界-社交拉氪模型.md new file mode 100644 index 0000000..5b3010b --- /dev/null +++ b/output/obsidian-vault/01-产品研究/花园世界-社交拉氪模型.md @@ -0,0 +1,50 @@ +--- +tags: [产品研究, 花园世界, 商业化, 社交拉氪] +created: 2026-06-02 +--- + +# 花园世界 — 社交拉氪模型 + +> 返回 [[花园世界研究总览]] + +## 核心理念 + +付费玩家的社交角色是**"被需要"**,不是"压制别人"。 + +付费买的是三样东西: +1. **可见性** — 花园参观、好友可见、公会主页 +2. **反馈性** — 摸花、互访、参观构成社交反馈循环 +3. **社会比较** — 稀有花、限定花、绝版花制造差异 + +## 底层理论 + +> 玩家付费买的核心不是数值,而是可见性、反馈性和社会比较。 + +## 付费路径(递进且自愿) + +``` +免费可玩 → 小额便利 → 图鉴收集 → 即时购买 +``` + +## 商业化方向:购物感与社会地位价值 + +花园主题天然让付费感知更接近**购物**: +- "我买了一朵好看的花" 比 "我买了碾压别人的力量" 更容易被休闲用户接受 +- 持续提供新的稀缺性内容——社会地位价值需要持续投入 + +## 与传统逼氪的区别 + +| 维度 | 传统逼氪 | 社交拉氪 | +|------|----------|----------| +| 付费动机 | 过不去才付费 | 在组织中有价值而付费 | +| 免费玩家体验 | 被边缘化 | 仍有基础价值 | +| 付费玩家角色 | 碾压者 | 被需要者 | +| 社交关系 | 对立 | 共生 | + +## 设计约束 + +- 免费玩家不能被系统边缘化,否则社交生态会塌 +- 付费玩家不能完全碾压,否则大通服崩塌 +- 传统资源压力仍需存在——社交拉氪不能替代全部商业化 + +相关:[[花园世界-商业化分析]]、[[花园世界-非战斗GVG]] diff --git a/output/obsidian-vault/01-产品研究/花园世界-美国版策略.md b/output/obsidian-vault/01-产品研究/花园世界-美国版策略.md new file mode 100644 index 0000000..a2d6f72 --- /dev/null +++ b/output/obsidian-vault/01-产品研究/花园世界-美国版策略.md @@ -0,0 +1,47 @@ +--- +tags: [产品研究, 花园世界, 美国版, 出海] +created: 2026-06-02 +source: 2026-05-25_report_my_garden_world_us_project.html +author: [[黄静雯]] +--- + +# 花园世界 — 美国版策略 + +> 返回 [[花园世界研究总览]] + +## 六面承重墙(复刻不能走形) + +| 承重墙 | 本质 | 改错了后果 | +|--------|------|-----------| +| 双层结构 | 第一层独立成立,第二层驱动变现 | 第一层太薄→留存崩 | +| 竞赛是需求放大器 | 放大图鉴收集需求 | 跟花种消耗脱钩→商业化断裂 | +| 氪金=被需要 | 高氪跟普通玩家共生 | 加入数值碾压→大通服崩塌 | +| 每周+次数有限 | 有目标但不绑每天 | 变日常→倦怠 | +| 资产跟人走 | 高流动+低损失+竞赛期锁定 | 绑公会→爆发性流失 | +| 大通服+小池匹配 | 社交池大+竞争可控 | 分服→鬼服 | + +## 美国版设计红线 + +1. 经营养成必须独立成立 +2. 限定花不垄断高价值任务 +3. 错过无严重惩罚 +4. 被公会踢的安全网默认做 + +## 行业参照:Gossip Harbor + +- 2025年总流水约6.5亿美元 +- iOS全球约60万评价4.58分 +- 月均流水约5400万美元 +- 团队约200-300人 + +## MVP验证路径 + +| 阶段 | 验证内容 | 判断指标 | +|------|----------|----------| +| 第1月 | 核心循环+多出口资源经济+可晒钩子 | 次留、自然分享率 | +| 第2月 | 异步贡献型组织目标(最小GVG) | 组织参与率、轻度玩家留存 | +| 第3月 | 分层商业化+一轮长短活动 | 付费转化、ARPPU、活动疲劳曲线 | + +止损线:三个月内任一指标远低于同类健康线且两轮迭代无改善。 + +相关:[[云湖工作室项目选择]]、[[花园世界-MVP验证方案]] diff --git a/output/obsidian-vault/01-产品研究/花园世界-非战斗GVG.md b/output/obsidian-vault/01-产品研究/花园世界-非战斗GVG.md new file mode 100644 index 0000000..e52b6f6 --- /dev/null +++ b/output/obsidian-vault/01-产品研究/花园世界-非战斗GVG.md @@ -0,0 +1,58 @@ +--- +tags: [产品研究, 花园世界, GVG, 公会, 社交设计] +created: 2026-06-02 +--- + +# 花园世界 — 非战斗GVG + +> 返回 [[花园世界研究总览]] + +## 定性 + +内部定义为:**"低协同、弱对抗、高覆盖、强分层、低焦虑的GVE型GVG"** + +它放大的是图鉴收集需求和资源用途优先级,而不是单纯增加消耗量。 + +## 设计原理:三大支柱 + +1. **异步参与**:不要求同时在线,每人有限次数 +2. **人人有贡献**:普通玩家提供基础价值,付费拉高上限但不碾压 +3. **贡献与奖励挂钩**:减少搭便车,个人贡献对应个人奖励 + +## 竞赛机制 + +- 每周竞赛,按段位分组 +- 有限参与次数(非无限刷) +- 任务分难度梯度:中低难度面向全体,高分任务需要当期付费花 +- 按公会总分排名,个人贡献决定个人奖励 + +## 为什么"只有养成、没有对抗"也能成立 + +传统逻辑:养成 → 战力释放 → 对抗检验 +花园世界:养成 → 满足 → 社交 → 再养成 + +竞争单位从个人换成公会: +- "我比你强" → "我们队比他们队强" +- "氪金=碾压" → "氪金=被需要" + +## 渐进路径 + +``` +低压习惯建立 + → 低侵入交互(雇佣、摸花、花贸市场) + → 发现"别人对我有用" + → 资源不够用,公会能提供更多渠道 + → 加入公会 + → 公会竞赛在已有经营循环里自然出现 +``` + +玩家进入公会的前期动力不是"想社交",而是**资源不够用了**。 + +## 大通服成立的四层条件 + +1. **消耗层**:资源被持续吃掉,老玩家不会囤出碾压性存量 +2. **资产层**:积累的是图鉴和效率,不是直接攻击别人的战力 +3. **匹配层**:小范围公会竞争,避免全服碾压 +4. **时间层**:缺席不产生进度惩罚,回归零摩擦 + +相关:[[非战斗GVG设计参数]]、[[花园世界-社交拉氪模型]] diff --git a/output/obsidian-vault/02-方法论/AI落地与组织变革.md b/output/obsidian-vault/02-方法论/AI落地与组织变革.md new file mode 100644 index 0000000..7ccddc9 --- /dev/null +++ b/output/obsidian-vault/02-方法论/AI落地与组织变革.md @@ -0,0 +1,45 @@ +--- +tags: [方法论, AI, 组织变革, 行业趋势] +created: 2026-06-02 +--- + +# AI落地与组织变革 + +> 返回 [[战略研究体系]] + +## 李志健的核心判断(2026-05-24) + +> "AI工具端的进步并没有转化为业务结果的最终变化。" + +> "行业正在快速洗牌,没有明显进步的就是在退步。" + +> "这一波AI军备竞赛,从业务到财务到管理层,跟不上的公司会迅速被淘汰。" + +## 关键问题 + +**为什么很多人用了AI但效率没有明显提升?** + +- 工程衔接上耗时的流程没有改变 +- 策划出方案到程序理解仍是最费时的环节 +- 测试、部署、体验验收没有AI自动化 +- 整个工作流的主干并没有减少人力 + +## 各方回应 + +| 人物 | 行动 | +|------|------| +| [[林峰]] | 强制所有人必须用AI,PM按AI流程重新排任务时间 | +| 汪雄军 | 将在厦门成立AI工作小组,专门研究落地和组织变革 | +| [[上官成]] | 提出米哈游智能体平台最接近理想方案 | + +## AI增效的三个维度 + +1. **缩短时间** = 既减少成本又增加市场反应速度 +2. **降低成本** = 增加利润 +3. **提升效果** = 提高ROI、用户口碑或收入 + +## 研究的根本目的 + +> 不是跟自己过去比,是跟未来的同行比。追求微小、可量化、能落地的相对竞争优势。一年内可见的、反应在业务财务收益上的价值。 + +相关:[[Game-Analyst-Agent工具]]、[[AI军备竞赛]] diff --git a/output/obsidian-vault/02-方法论/取败之道-战略反思.md b/output/obsidian-vault/02-方法论/取败之道-战略反思.md new file mode 100644 index 0000000..11977eb --- /dev/null +++ b/output/obsidian-vault/02-方法论/取败之道-战略反思.md @@ -0,0 +1,59 @@ +--- +tags: [方法论, 战略, 李志健, 反思] +created: 2026-06-02 +source: 取败之道.md +author: [[李志健]] +--- + +# 取败之道 — 战略反思 + +> 返回 [[战略研究体系]] + +## 核心公式 + +``` +负期望博弈 + 极端幸存者偏差 + 没有筹码管理 = 取败之道 +微弱正期望 + 筹码管理 + 持续参与 = 取胜之道 +``` + +## 四个致命心理机制 + +1. **沉没成本谬误**:已经投入这么多,放弃就全白费 +2. **能力幻觉**:觉得自己足够聪明一定能破局 +3. **窗口期焦虑**:觉得机会稍纵即逝必须all in +4. **资源的止痛效应**:有钱=容错空间大=反馈信号弱 + +## 关键金句 + +> "钱是组织的止痛药。止痛药让你在骨折的时候还能跑。跑着跑着骨头就碎了。" + +> "挣小钱的心态 = 低成本、高频试错、反馈极快 = 正期望博弈最佳姿态。" + +> "资源充裕本身就是生长逻辑的天敌。" + +> "假说是手电筒,不是隧道。手电筒照亮一个方向,但你眼角余光看到的东西可能比正前方更重要。" + +## 非对称博弈四条原则 + +1. **保护下限**:永远不把全部筹码押在一把上 +2. **多次参与**:每次成本低、速度快 +3. **不追求最优解**:最优解=集中全部资源=最危险 +4. **让每次试错都产生学习**:输了不是白输 + +## 组织启示 + +- 在现有组织旁边长出极小的试验体 +- 让关键决策者重新回到一线 +- 用结构保证纪律,不靠意志力 +- 抵制"从成功中提炼方法论"的冲动 + +## 生长逻辑 vs 规划逻辑 + +| 维度 | 生长逻辑 | 规划逻辑 | +|------|----------|----------| +| 前提 | 不知道答案 | 假设已知方向 | +| 方式 | 高频试错接触现实 | 制定行动方案 | +| 反馈 | 直接承受后果 | 通过报告了解 | +| 风险 | 每次试错代价小 | 单次投入高周期长 | + +相关:[[腰部底座识别方法]]、[[立项评估框架]] diff --git a/output/obsidian-vault/02-方法论/立项评估框架.md b/output/obsidian-vault/02-方法论/立项评估框架.md new file mode 100644 index 0000000..0552f7b --- /dev/null +++ b/output/obsidian-vault/02-方法论/立项评估框架.md @@ -0,0 +1,44 @@ +--- +tags: [方法论, 立项, 评估框架] +created: 2026-06-02 +--- + +# 立项评估框架 + +> 返回 [[战略研究体系]] + +## 6问检查清单 + +新项目方案里**必须回答**这6个问题: + +1. **我们借鉴的是哪个已验证底座**,而不是只说对标哪个爆款? +2. **这个底座为什么没有被原团队放大?** +3. **我们能放大的能力是什么?** +4. **核心资源是否有多个消耗出口?** +5. **是否能做低压、异步、人人有贡献的组织目标?** +6. **玩家有什么结果可以拿到外部平台展示?** + +> 如果这6个问题答不清,项目很容易变成"系统很多,但没有放大杠杆"。 + +## 五步评估法 + +### A. 找底座 +- 核心循环成立? +- 用户愿意长期回来? +- 有自然社交或展示需求? +- 有付费用户存在? +- 有社区自发攻略/招新/交流? + +### B. 找短板 +原产品为什么没做大:画面老?买量素材弱?商业化浅?活动密度低?社交组织弱? + +### C. 找放大能力 +公司能补什么:美术升级?题材包装?短视频素材?商业化设计?长线活动?公会生态? + +### D. 找外部传播点 +玩家能晒什么:成果?身份?稀缺物?作品?情绪?现实权益?团队荣誉? + +### E. 找风险 +放大后最可能出问题在哪里:履约?客服?活动肝度?大R垄断?轻度用户流失? + +相关:[[腰部底座识别方法]]、[[取败之道-战略反思]] diff --git a/output/obsidian-vault/02-方法论/腰部底座识别方法.md b/output/obsidian-vault/02-方法论/腰部底座识别方法.md new file mode 100644 index 0000000..0135591 --- /dev/null +++ b/output/obsidian-vault/02-方法论/腰部底座识别方法.md @@ -0,0 +1,46 @@ +--- +tags: [方法论, 立项, 识别方法] +created: 2026-06-02 +--- + +# 腰部底座识别方法 + +> 返回 [[战略研究体系]] + +## 四条判断标准 + +### 1. 已被验证 +核心循环已被用户验证(留存/付费结构成立)。 + +问自己:这个产品的核心循环是否有数据支撑? + +### 2. 有放大空间 +美术、传播、商业化、长期运营至少有一层**明显没做透**。 + +问自己:它为什么没做大?是能力问题还是结构问题? + +### 3. 我方有代差 +自问"我方相比原产品能在哪一层形成代差"——题材包装、买量素材、社交生态、商业化深度、长期运营产能,至少一项有明确优势。 + +### 4. 能力短板而非结构问题 +- 如果只是营销/美术/商业化等**能力短板**(如秘密花园HD)→ 有放大空间 +- 如果是核心循环或需求本身见顶 → 放大也无效 + +## 从竞品拆"已验证结构"的方法 + +拆解时把"玩法清单"与"已验证结构"分开: +- **玩法清单**可抄 +- **已验证结构**(核心循环 × 资源枢纽 × 组织绑定 × 留存层级)才是真正的底座资产 + +## 案例:花园世界 vs 秘密花园HD + +| 维度 | 秘密花园HD | 花园世界 | +|------|-----------|----------| +| 核心循环 | 相同(种花→收获→订单→社交) | 相同 | +| 系统完整度 | 完整 | 更精炼 | +| 营销 | 近乎空白 | 真花钩子+短剧+代言 | +| 美术 | Q版古风,显古早 | 仿唐国风,治愈系 | +| 商业化 | IAP为主,深度不足 | 社交拉氪+极致消耗 | +| 结果 | 月收入百万级 | 月收入4-5亿级 | + +相关:[[花园世界-底座溯源]]、[[取败之道-战略反思]] diff --git a/output/obsidian-vault/02-方法论/非战斗GVG设计参数.md b/output/obsidian-vault/02-方法论/非战斗GVG设计参数.md new file mode 100644 index 0000000..47a7f3b --- /dev/null +++ b/output/obsidian-vault/02-方法论/非战斗GVG设计参数.md @@ -0,0 +1,40 @@ +--- +tags: [方法论, GVG, 设计参数, 机制设计] +created: 2026-06-02 +--- + +# 非战斗GVG设计参数 + +> 返回 [[战略研究体系]] | 参考 [[花园世界-非战斗GVG]] + +## 设计原则 + +1. **异步参与**:不要求同时在线 +2. **人人有贡献**:普通玩家也能提供基础价值 +3. **付费拉高上限但不碾压** +4. **个人贡献和奖励挂钩**:减少搭便车 +5. **分层赛段**:避免轻度玩家被赶走 + +## 可做GVG的行为 + +- 种植贡献、订单贡献、装修贡献 +- 收集贡献、制作贡献、探索贡献 +- 互助贡献、投票贡献、展示贡献 + +## 迁移案例 + +| 品类 | GVG形式 | +|------|---------| +| 宠物项目 | 公会共同照顾动物园、完成救助任务 | +| 餐厅项目 | 联盟共同筹备宴会、完成订单季赛 | +| 家园项目 | 社区共同建设街区、参与主题装修赛 | +| 换装项目 | 社团共同完成秀场主题 | +| 农场项目 | 村庄共同完成订单、节庆、贸易目标 | + +## 核心设计约束 + +> 个人日常行为可以异步累积成组织目标。 + +这是休闲项目长线化的重要方向。 + +相关:[[花园世界-非战斗GVG]]、[[立项评估框架]] diff --git a/output/obsidian-vault/03-项目落地/Game-Analyst-Agent工具.md b/output/obsidian-vault/03-项目落地/Game-Analyst-Agent工具.md new file mode 100644 index 0000000..4b73942 --- /dev/null +++ b/output/obsidian-vault/03-项目落地/Game-Analyst-Agent工具.md @@ -0,0 +1,71 @@ +--- +tags: [工具, 自动化, 竞品分析, 黄静雯] +created: 2026-06-02 +source: game-analyst-agent-manual.html + game-analyst-agent.zip +author: [[黄静雯]] +version: v1.7.0 +--- + +# Game Analyst Agent 工具 + +> 返回 [[花园世界研究总览]] + +## 定位 + +通用游戏/网页深度分析自动化工具——自动探索界面、提取机制与数值、多游戏对比、活动追踪、决策报告生成。 + +## 六大能力 + +| 能力 | 说明 | +|------|------| +| 自主界面探索 | Android模拟器+浏览器双模式,9级优先级决策链 | +| 机制规则+数值提取 | AI视觉模型分析截图,提取规则和数值事实 | +| 多游戏横向对比 | 跨游戏规则按module对齐,HTML对比矩阵 | +| 活动追踪 | 定时重跑检测界面变化,输出变化时间线 | +| 市场数据采集 | 七麦/SensorTower/榜单 | +| 决策报告生成 | 多游戏数据+AI综合分析,面向管理层 | + +## 使用方式 + +```bash +# 安装 +pip install -e ".[all]" + +# 配置 +cp .env.example .env # 填入API Key + +# 自检 +game-analyst doctor + +# 初始化 +game-analyst init --game my_garden + +# 探索 +game-analyst explore --game my_garden + +# 对比 +game-analyst compare --games a,b,c + +# 决策报告 +game-analyst decision-report --games a,b --question "商业化结构如何" +``` + +## 成本 + +- 探索阶段:**完全免费**(本地OpenCV) +- 分析阶段:国产模型24h连续运行 **< 1元** + +## 支持模型 + +| 模型 | 成本 | 推荐场景 | +|------|------|----------| +| 阿里通义Qwen-VL | ~0.003元/张 | 日常分析(推荐) | +| 字节豆包Vision | ~0.002元/张 | 极低成本 | +| Claude Sonnet | 标准API价 | 高精度 | + +## 文件位置 + +- 源码:`dc_html_md/game-analyst-agent/`(294KB zip已解压) +- 说明书:`dc_html_md/game-analyst-agent-manual.html` + +相关:[[AI落地与组织变革]] diff --git a/output/obsidian-vault/03-项目落地/云湖工作室项目选择.md b/output/obsidian-vault/03-项目落地/云湖工作室项目选择.md new file mode 100644 index 0000000..5e01138 --- /dev/null +++ b/output/obsidian-vault/03-项目落地/云湖工作室项目选择.md @@ -0,0 +1,52 @@ +--- +tags: [项目落地, 云湖, 立项, 花园经营] +created: 2026-06-02 +source: 2026-05-yunhu-project-selection-strategy-report.html +author: [[黄静雯]] +--- + +# 云湖工作室项目选择 + +> 返回 [[花园世界研究总览]] + +## 背景 + +- 团队:约16人(策划4、程序5、美术5、制作人2) +- 目标:2个月开发 + 第3个月上线测试 +- 市场:面向美国 +- 约束:不做3D、重战斗、长周期原创大项目 + +## 推荐排序 + +### 第一优先:欧美化花园/庄园/花店经营养成 + +推荐理由: +- 系统复杂度低,MVP范围可控 +- AI美术适配度高(2D插画、轻松治愈风格) +- 素材测试效率高 +- 失败后资产复用度高 +- 参照产品验证:[[我的花园世界-产品画像|花园世界]]具备长线运营潜力 +- 文化摩擦低 +- 泛用户定位与公司经验一致 + +**注意**:不是商业化确定性最高的方向,而是**交付确定性最高、验证成本最低、失败后资产复用度最高**的首选。 + +### 第一梯队备选:欧美化泛用户历史/家族/宫廷养成 + +- 商业化确定性更高(公司有万岁爷/GOS/GOK完整模板) +- 但系统复杂度高,2个月出MVP挑战大 + +### 备选:宠物/奇幻生物/轻培育经营 + +- 底层循环与花园高度同构 +- 花园方向不理想时可快速切换 + +## 验证方式 + +| 阶段 | 动作 | +|------|------| +| 第1周 | 花园/庄园/花店多组素材投放测试(CTR/CPI) | +| 第1-2周 | 并行完成花园世界商业化结构深拆 | +| 第2周 | 综合素材数据+商业化深拆结论,判断是否继续 | + +相关:[[花园世界-MVP验证方案]]、[[花园世界-美国版策略]] diff --git a/output/obsidian-vault/03-项目落地/花园世界-MVP验证方案.md b/output/obsidian-vault/03-项目落地/花园世界-MVP验证方案.md new file mode 100644 index 0000000..ec819cd --- /dev/null +++ b/output/obsidian-vault/03-项目落地/花园世界-MVP验证方案.md @@ -0,0 +1,50 @@ +--- +tags: [项目落地, MVP, 验证, 花园世界] +created: 2026-06-02 +--- + +# 花园世界 — MVP验证方案 + +> 返回 [[花园世界研究总览]] + +## 三个月验证路径 + +### 第1月:核心循环验证 +- 核心循环 + 多出口资源经济 +- 一个"可晒结果"钩子 +- **验证**:次留与自然分享率 + +### 第2月:组织目标验证 +- 接入异步贡献型组织目标(最小可用GVG) +- **验证**:组织参与率与轻度玩家留存 + +### 第3月:商业化验证 +- 叠加分层商业化 + 一轮长短活动 +- **验证**:付费转化、ARPPU与活动疲劳曲线 + +## 止损判断 + +三个月内若以下任一项远低于同类健康线,且两轮迭代无改善 → 触发方向复盘/止损: + +- 自然分享率 +- 组织参与率 +- 付费转化 + +参考指标:付费次留 >70%、次~30留 >45% + +## 必备团队能力 + +1. 营销破圈(女频短剧素材 + 代言/话题 + 短视频买量产能) +2. 社交系统设计(异步贡献型组织、资源错配、换花/互助网络) +3. 重后端商业化(订阅/礼包/累充/稀缺冲榜/IAA的分层组合) +4. 长期运营产能(每1-2月补系统 + 双层错频活动) +5. (若做实物)履约与客服 + +## 最大风险 + +1. 只换皮、不明确"没做透的环节" → 复制了天花板 +2. 只加排行榜当GVG → 劝退轻度玩家 +3. 把实物奖励当福利 → 履约跟不上反噬 +4. 活动高密度但无层级 → 信息过载 + +相关:[[云湖工作室项目选择]]、[[花园世界-美国版策略]] diff --git a/output/obsidian-vault/04-人物/人物图谱.md b/output/obsidian-vault/04-人物/人物图谱.md new file mode 100644 index 0000000..cda88fa --- /dev/null +++ b/output/obsidian-vault/04-人物/人物图谱.md @@ -0,0 +1,47 @@ +--- +tags: [人物, 组织] +created: 2026-06-02 +--- + +# 人物图谱 + +> dc战略问题研究院 + 创新组 28位活跃人员 + +## 核心决策层 + +| 人物 | 角色 | 消息数 | 主要贡献 | +|------|------|--------|----------| +| [[李志健]] | 战略方向制定者 | 121 | 主报告、战略反思、AI紧迫性讨论 | +| [[黄静雯]] | 研究执行主力 | 31 | 美国版策略、云湖方案、Agent工具 | + +## 战略研究组 + +| 人物 | 方向 | 消息数 | +|------|------|--------| +| [[陈楚真]] | 商业化深度研究、Kimi报告 | 24 | +| [[夏莲]] | 竞品数据、社区分析 | 22 | +| [[张家振]] | 市场数据、品类趋势 | 20 | +| [[胡辉俊]] | 用户画像、留存分析 | 17 | +| [[莫润麟]] | 机制拆解、数值分析 | 17 | +| [[汪季]] | 行业对标、发行策略 | 11 | +| [[傅明游]] | GOS侧实测数据 | 5 | + +## 创新组 + +| 人物 | 方向 | 消息数 | +|------|------|--------| +| [[王雨默]] | 二合游戏研发、工作流 | 21 | +| [[韦译]] | AI工具使用、研发 | 20 | +| [[刘鹏]] | UI编辑器、AI美术 | 13 | +| [[卓泽]] | 日报、研发 | 12 | +| [[徐锐]] | 冰雪餐厅主题 | 6 | + +## 跨组/支持 + +| 人物 | 角色 | 消息数 | +|------|------|--------| +| [[上官成]] | 技术架构、AI观点 | 8 | +| [[林峰]] | 工作室负责人、AI落地 | 3 | +| [[安东]] | 发行、AI落地 | 2 | +| 汪雄军 | 厦门AI工作小组 | 1 | +| [[黄祥钦]] | 竞品补充(梦想小镇) | 1 | diff --git a/output/obsidian-vault/04-人物/李志健.md b/output/obsidian-vault/04-人物/李志健.md new file mode 100644 index 0000000..59a01f8 --- /dev/null +++ b/output/obsidian-vault/04-人物/李志健.md @@ -0,0 +1,28 @@ +--- +tags: [人物, 战略, 决策者] +--- + +# 李志健 + +> [[人物图谱]] + +## 角色 +战略方向制定者,dc战略问题研究院和创新组的最高决策者。 + +## 核心贡献 +- 花园世界研究主报告(90KB,最完整的研究输出) +- "取败之道"战略反思 +- 策划启示、进一步思考 +- AI落地紧迫性讨论 +- 研究根本目的定义 + +## 核心观点 +- "不要学种花题材,要学已验证底座+放大能力" +- "AI工具端的进步并没有转化为业务结果的最终变化" +- "研究应聚焦解决业务部门当前具体问题" +- "追求微小、可量化、能落地的相对竞争优势" + +## 关联 +- [[取败之道-战略反思]] +- [[AI落地与组织变革]] +- [[花园世界研究总览]] diff --git a/output/obsidian-vault/04-人物/黄静雯.md b/output/obsidian-vault/04-人物/黄静雯.md new file mode 100644 index 0000000..910afba --- /dev/null +++ b/output/obsidian-vault/04-人物/黄静雯.md @@ -0,0 +1,28 @@ +--- +tags: [人物, 研究, 工具] +--- + +# 黄静雯 + +> [[人物图谱]] + +## 角色 +战略研究执行主力,同时横跨dc战略问题研究院和创新组。 + +## 核心贡献 +- 美国版产品策略报告(46KB) +- 云湖工作室项目选择报告(40KB) +- Game Analyst Agent工具(294KB完整源码) +- 飞书MCP Server(自动知识提取) +- 每日研究日报(8篇+) + +## 工作方式 +- 用Claude Code读取飞书云文档中的原始报告 +- 用HTML格式输出研究结果(可读性高) +- 构建自动化工具加速竞品分析 +- 知识卡片系统(MECH/REPORT/ORG卡片) + +## 关联 +- [[Game-Analyst-Agent工具]] +- [[花园世界-美国版策略]] +- [[云湖工作室项目选择]] diff --git a/output/obsidian-vault/05-行业趋势/AI军备竞赛.md b/output/obsidian-vault/05-行业趋势/AI军备竞赛.md new file mode 100644 index 0000000..6853d2d --- /dev/null +++ b/output/obsidian-vault/05-行业趋势/AI军备竞赛.md @@ -0,0 +1,35 @@ +--- +tags: [行业趋势, AI, 竞争] +created: 2026-06-02 +--- + +# AI军备竞赛 + +> 返回 [[战略研究体系]] + +## 行业现状(2026年5月) + +- AI在中国游戏研发端整体普及率已达**86.36%** +- 腾讯VISVISE已应用于近100个游戏项目,效率最高提升8倍 +- 贪玩游戏AI渗透率超80%,2025年净利润15.6亿元 + +## 李志健的核心忧虑 + +> "没有公司不用AI的,没有公司不在研究怎么用AI的。最关键的差别在于**谁落到了业务结果上**。" + +> "这一波AI军备竞赛,从业务到财务到管理层,跟不上的公司会迅速被淘汰。" + +## 问题所在 + +AI提效5-10倍,但企业绩效增长不到5%。效率的提升被组织内部的管理和结构性矛盾给消化掉了。 + +**这不是AI不好用,是组织的刚性把所有增量都吃掉了。** + +## 应对策略 + +1. 强制所有人必须用AI(林峰的做法) +2. PM必须按AI流程重新排任务时间 +3. 成立专门AI工作小组研究落地(汪雄军) +4. 端到端提效要传导到业务结果上 + +相关:[[AI落地与组织变革]]、[[Game-Analyst-Agent工具]] diff --git a/output/obsidian-vault/05-行业趋势/休闲入口嫁接中重度运营.md b/output/obsidian-vault/05-行业趋势/休闲入口嫁接中重度运营.md new file mode 100644 index 0000000..be5296e --- /dev/null +++ b/output/obsidian-vault/05-行业趋势/休闲入口嫁接中重度运营.md @@ -0,0 +1,40 @@ +--- +tags: [行业趋势, 出海, 商业模式] +created: 2026-06-02 +--- + +# 休闲入口嫁接中重度运营 + +> 返回 [[花园世界研究总览]] + +## 核心判断 + +以Gossip Harbor为代表,"休闲入口+中重度运营"在美国市场**不是偶然现象,而是已被多类产品反复验证的出海方向**。 + +## Gossip Harbor核心数据 + +| 指标 | 数据 | +|------|------| +| 2025年总流水 | 约6.5亿美元 | +| iOS评分 | 全球4.58分,美国4.6分 | +| 月均流水 | 约5400万美元 | +| 月复合增长 | 约9% | +| 团队规模 | 200-300人 | +| 更新频率 | 每月约4次 | + +## 竞争已进入执行细节阶段 + +差异化不再是方向选择,而是: +1. 基础玩法谁更顺 +2. 内容产能谁更稳定 +3. 商业化深度谁更强 +4. 买量素材与产品联动谁更好 +5. 谁能长期维持用户不反感 + +## 对美国版的启发 + +- 欧美休闲用户可以接受中重度运营,前提是底层手感顺滑 +- 活动内容产能是生死线 +- 核心玩法和数值底座必须足够有弹性 + +相关:[[花园世界-增长飞轮]]、[[花园世界-美国版策略]] diff --git a/output/obsidian-vault/06-数据与索引/关键概念索引.md b/output/obsidian-vault/06-数据与索引/关键概念索引.md new file mode 100644 index 0000000..7131076 --- /dev/null +++ b/output/obsidian-vault/06-数据与索引/关键概念索引.md @@ -0,0 +1,42 @@ +--- +tags: [索引, 概念] +created: 2026-06-02 +--- + +# 关键概念索引 + +## 产品机制类 + +| 概念 | 含义 | 首次出现 | +|------|------|----------| +| 低压经营 | 低门槛、低焦虑、低侵入的经营体验 | 主报告 | +| 极致消耗 | 玩家长期处于"有花但不够用" | 主报告 | +| 非累计式任务 | 历史积累不能减免当次消耗 | 主报告 | +| 双层结构 | 低压经营入口+极致消耗变现 | 美国版报告 | +| 大通服 | 社交池大+竞争可控+永远不鬼服 | 美国版报告 | + +## 商业化类 + +| 概念 | 含义 | 首次出现 | +|------|------|----------| +| 社交拉氪 | 让玩家因在组织中有价值而付费 | 主报告 | +| 规划焦虑型付费 | 因资源规划压力而非即时冲动付费 | 主报告 | +| 购物感 | 付费感知接近购物而非买战力 | 主报告 | +| 社会地位价值 | 稀缺性内容制造社交差异 | 主报告 | + +## 立项方法类 + +| 概念 | 含义 | 首次出现 | +|------|------|----------| +| 腰部底座 | 已被验证但未被充分放大的产品结构 | 策划启示 | +| 放大能力 | 美术/营销/商业化/运营的系统性提升 | 主报告 | +| 非战斗GVG | 不依赖战斗的公会组织竞争模式 | 主报告 | + +## 战略思维类 + +| 概念 | 含义 | 首次出现 | +|------|------|----------| +| 取败之道 | 负期望博弈+幸存者偏差+无筹码管理 | 取败之道 | +| 生长逻辑 | 高频试错中长出方向,非规划得出 | 取败之道 | +| 筹码管理 | 控制单次投入,保留多次参与能力 | 取败之道 | +| 非对称博弈 | 赢时赢得多、输时输得少、永不出局 | 取败之道 | diff --git a/output/obsidian-vault/06-数据与索引/研究组日报索引.md b/output/obsidian-vault/06-数据与索引/研究组日报索引.md new file mode 100644 index 0000000..6d2ed24 --- /dev/null +++ b/output/obsidian-vault/06-数据与索引/研究组日报索引.md @@ -0,0 +1,39 @@ +--- +tags: [索引, 日报, 飞书] +created: 2026-06-02 +--- + +# 研究组日报索引 + +> dc战略问题研究院 7位成员每日研究报告(05-25至06-02) + +## 成员与飞书空间 + +| 成员 | 飞书域 | 研究方向 | +|------|--------|----------| +| [[黄静雯]] | dianchukeji.feishu.cn | 产品机制、商业化、美国版策略 | +| [[陈楚真]] | dianchukeji.feishu.cn | 商业化梳理、资源经济、Kimi深度研究 | +| [[夏莲]] | fcnlycv6dd0w.feishu.cn | 竞品数据、社区分析 | +| [[张家振]] | ocnmca6f1o0p.feishu.cn | 市场数据、品类趋势 | +| [[莫润麟]] | fcnlycv6dd0w.feishu.cn | 机制拆解、数值分析 | +| [[胡辉俊]] | fcnlycv6dd0w.feishu.cn | 用户画像、留存分析 | +| [[汪季]] | my.feishu.cn | 行业对标、发行策略 | + +## 飞书域说明 + +- **dianchukeji.feishu.cn**:公司飞书(可直接HTTP访问部分内容) +- **fcnlycv6dd0w.feishu.cn**:研究组飞书空间(需登录) +- **ocnmca6f1o0p.feishu.cn**:另一飞书空间(需登录) +- **my.feishu.cn**:个人飞书(需登录) + +## 日报提交规律 + +- 每人每天提交1篇 +- 统一在凌晨1-3点或上午9点左右提交 +- 黄静雯和陈楚真偶尔额外提交工具/专题报告 + +## 完整链接列表 + +全部190个飞书链接已保存在 `knowledge_graph.json` 的 documents 字段中。 + +相关:[[人物图谱]]、[[花园世界研究总览]] diff --git a/output/obsidian-vault/06-数据与索引/花园世界核心数据.md b/output/obsidian-vault/06-数据与索引/花园世界核心数据.md new file mode 100644 index 0000000..0e35c66 --- /dev/null +++ b/output/obsidian-vault/06-数据与索引/花园世界核心数据.md @@ -0,0 +1,47 @@ +--- +tags: [数据, 花园世界] +created: 2026-06-02 +--- + +# 花园世界核心数据 + +> 返回 [[花园世界研究总览]] + +## 产品数据 + +| 指标 | 数据 | 来源 | 可信度 | +|------|------|------|--------| +| 峰值DAU | 千万级 | 官方/媒体 | ✅ | +| 峰值月流水 | 4-5亿元 | 推算 | ⚠️ | +| iOS免费榜 | 霸榜约2周 | 媒体 | ✅ | +| iOS畅销榜 | 前5 | 媒体 | ✅ | +| Google Play下载 | 100万+ | 商店页 | ✅ | +| Google Play评分 | 4.5 | 商店页 | ✅ | +| 美国App Store评分 | 4.7 | 商店页 | ✅ | +| TapTap评分 | 7.8 | 商店页 | ✅ | +| TapTap下载 | ~30万 | 商店页 | ✅ | +| 美国iOS下载榜 | Top 4 | 虎嗅/搜狐 | ✅ | + +## 与秘密花园HD对比 + +| 维度 | 秘密花园HD | 花园世界 | 倍差 | +|------|-----------|----------|------| +| 月收入 | 百万级 | 4-5亿级 | 50-100x | +| 畅销榜最高 | ~第40名 | 前5 | - | +| 营销投入 | 近乎空白 | 大规模 | - | + +## Gossip Harbor参照 + +| 指标 | 数据 | +|------|------| +| 2025年总流水 | ~6.5亿美元 | +| 月均流水 | ~5400万美元 | +| 月复合增长 | ~9% | +| iOS评分 | 4.58(全球)/ 4.6(美国) | + +## GOS实测 + +- 低压力循环复刻活动效果 > 常规活动 +- GOK/VK SLG融合可做到1.5-2倍LTV差异 + +相关:[[我的花园世界-产品画像]]、[[花园世界-GOS补充数据]] diff --git a/output/reports/final_report.md b/output/reports/final_report.md new file mode 100644 index 0000000..20b5cad --- /dev/null +++ b/output/reports/final_report.md @@ -0,0 +1,323 @@ +# 钉钉群飞书链接综合分析报告(完整版) +> 生成时间:2026-05-26 | 共分析 33 条记录,提取 27 篇文档正文 + +--- + +## 一、团队全景 + +这是一个**跨公司的游戏行业研究团队**,通过钉钉群每日分享飞书日报。 + +### 核心成员 + +| 成员 | 租户 | 身份 | 核心方向 | 文档可读性 | +|------|------|------|---------|-----------| +| **汪季** | my.feishu.cn | AI游戏开发探索者 | IAA手游从0到1、AI编程助手 | ✅ 全文(6篇) | +| **陈楚真** | dianchukeji(厦门点触科技) | 游戏策划/生态分析师 | SLG游戏设计、私服生态、公会系统 | ✅ 全文(5篇) | +| **夏莲** | fcnlycv6dd0w(用户239707) | 深圳研究部 | 学术研究:平台治理、综合投入变量 | ✅ 全文(5篇) | +| **莫润麟** | fcnlycv6dd0w(用户239707) | 深圳研究部 | 峰值策略数值模拟、博弈论 | ✅ 全文(5篇) | +| **胡辉俊** | fcnlycv6dd0w(用户239707) | 深圳研究部 | AI美术工作流、像素资产生产 | ✅ 全文(4篇) | +| **张家振** | ocnmca6f1o0p(用户306954) | 游戏策划/AI美术 | AI+Spine动画、塔防游戏设计 | ✅ 全文(5篇) | +| **黄静雯** | dianchukeji(厦门点触科技) | 创新组 | game-analyst-agent、产品策略 | ✅ 全文(3篇) | +| **李志健** | - | - | 分享聊天记录 | ❌ 无内容 | + +> 深圳研究部(夏莲、莫润麟、胡辉俊)曾共同参与《三国:谋定天下》专题研讨会 + +--- + +## 二、各成员工作内容深度分析 + +### 2.1 汪季 — AI 驱动游戏开发全流程 + +**核心项目:《元素合成守卫》**(竖屏塔防合成 IAA 手游) +技术栈:Godot 4.6 + GDScript | 目标:iOS/Android | 画面:高饱和新国风幻想 + +#### 日报时间线 + +| 日期 | 核心主题 | +|------|---------| +| 5.19 | 游戏行业 AI 编程助手调研(MagicAI/Astrocade/Genie3)+ 复盘会思考 | +| 5.20 | IAA方案对抗收敛:Claude Code + Codex V1→V5推演链,选定元素合成守卫 | +| 5.21 | Block Blast虚拟玩家系统 + 游戏设计突破:首发方向/视觉/地图 | +| 5.22 | 系统设计20/20完成 + 架构决策(ADR)+ 测试基础 | +| 5.23 | 8大工程基座体系 + Spine工具链调研(结论:暂无可用AI Spine工具) | +| 5.25 | Steam像素游戏美术生产分析 + 序列帧vs Spine混合方案 | + +#### 核心知识产出 + +**1. AI对抗式方案收敛法** +``` +Claude Code 提出方向 → Codex 攻击漏洞 → 修正收紧 → 循环 +``` + +**2. AI游戏8大工程基座** +决策 → 任务 → 验证 → 数据 → 实验 → 内容 → 回归 → 运营 + +**3. 多窗口并行协作法** +主窗口压缩上下文 → 子窗口分组继承 → 按策划内容分工 → 汇总 + +--- + +### 2.2 陈楚真 — SLG 游戏生态深度分析 + +#### 日报时间线 + +| 日期 | 核心主题 | +|------|---------| +| 5.20 | 《三国:谋定天下》私服泛滥观察:运营节奏偏差 + 源码泄露 + 黑产专业化 | +| 5.21 | 《我的花园世界》前三天留存设计:节奏驯化 + 零摩擦回归 + 永动机制 | +| 5.25 | 《我的花园世界》公会系统:降本增效系统 + KPI驱动的微缩社会 + 研究目的校准 | + +#### 核心分析框架 + +**三谋私服爆发模型:** +- 根本诱因:开发库深度泄露 + 黑产专业化运作 +- 时间触发:二周年延期 → 长草期真空 → 私服作为替补消费 +- 玩家心理三阶段:数值压力释放 → 虚假繁荣 → 资产安全焦虑 + +**《我的花园世界》留存设计:** +- 节奏驯化:碎片化时间切割 + 密集奖励派发 → 条件反射式习惯 +- 永动机制:无任务终结 + 水滴经济循环 + +**公会系统洞察:** +- 公会不是社交容器,是商业化后期的流量过滤与资源回收池子 +- KPI驱动的"微缩社会":压力驱使下的群体永动 + +--- + +### 2.3 夏莲 — 学术研究:平台治理与综合投入 + +#### 日报时间线 + +| 日期 | 核心主题 | +|------|---------| +| 5.20 | Claude Code长文档读取测试(64页开题报告)+ 论文推进方案制定 | +| 5.21 | 研究设计验证:综合投入构造 + 文献支撑 + 游戏案例外部样本初筛 | +| 5.22 | 规则变量与综合投入构造流程 + 博弈论-公平性机制 | +| 5.23 | 会议记录 + 基尼系数G + 竞赛奖励结构 | +| 5.25 | 开题报告反馈调整汇总(6个问题)+ 财务AI需求讨论 | + +#### 核心学术框架 + +**综合投入公式:** +``` +x_it = α·K_it + (1-α)·L_it +``` +- K:货币投入 +- L:有效行为投入 +- 七大机制属于 X 侧(解释变量),不参与公式计算 + +**AI应用核心观点(会议提炼):** +> "AI应用的核心不是技术先进性,而是业务有效性。" +> "真正有价值的AI工作流,应当能进入项目生产链条,解决实际问题。" + +--- + +### 2.4 莫润麟 — 峰值策略数值模拟与博弈论 + +#### 日报时间线 + +| 日期 | 核心主题 | +|------|---------| +| 5.20 | 峰值策略数值模拟:Real Options + Discovery-Driven Growth + Monte Carlo | +| 5.21 | 竞赛活动主案例评估(烽火逐盟 vs 钲鼓连烽)+ 数值模拟初跑 | +| 5.22 | 开题答辩问题梳理 + 飞书云文档接入Obsidian知识库 | +| 5.23 | 会议内容(企业本质=创造优势)+ PPT汇报思路 + 私有性机制映射 | + +#### 核心理论框架 + +**峰值策略三大理论支撑:** +1. Real Options(Lenos Trigeorgis, 1996):先小规模探索,根据反馈决定是否加码 +2. Discovery-Driven Growth(McGrath & MacMillan, 2009):先设定假设,最小成本验证 +3. Monte Carlo & Dynamic Simulation:变量显式化、参数化、系统测试 + +**竞争优势论(会议核心):** +> "企业的本质是创造优势,不只是满足需求。" +> "优势的来源不在于规模,而在于在关键环节比对手做得更好的能力。" + +--- + +### 2.5 胡辉俊 — AI 美术工作流与像素资产生产 + +#### 日报时间线 + +| 日期 | 核心主题 | +|------|---------| +| 5.22 | Block AI用户行为模拟平台研究 + AI创意生成工具进度 | +| 5.23 | 研究目标梳理:带来可量化的竞争优势 + AI美术工作流测试 | +| 5.25 | AI像素美术工作流深入 + Fake Pixel问题调研 | + +#### 核心发现 + +**Block AI的前置预判价值:** +``` +传统:版本 → 真实A/B测试 → 看数据 → 迭代 +Block AI:版本 → AI模拟用户行为 → 先筛掉明显问题 → 再进A/B +``` + +**AI像素美术的核心陷阱 — Fake Pixel:** +- AI生成的"像素风"≠ 可用的像素资产 +- 关键判断:放大后是否保持规整像素网格、无模糊边/抗锯齿 +- 完整工作流:生成 → 标准化 → 切帧 → 对齐 → 质检 → 工程接入 + +**竞争优势的务实标准:** +> "比同行成本更低、速度更快,或者成功率更高。" + +--- + +### 2.6 张家振 — AI+Spine动画与塔防游戏设计 + +#### 日报时间线 + +| 日期 | 核心主题 | +|------|---------| +| 5.20 | Claude Code Game Studios:49个AI智能体 + 72个技能命令的虚拟工作室 | +| 5.21 | 塔防游戏策划案:浮桥造路 + 炮塔分类 + 怪物AI决策 | +| 5.22 | 边界锁定与系统工程拆解:24个系统,已完成6个核心地基系统 | +| 5.25 | Spine接入方案:T-pose生成 + 6部位切分(VLM+SAM2) | + +#### 核心发现 + +**Claude Code Game Studios(49智能体架构):** +- 总监层:创意总监/技术总监/制作人 +- 部门负责人:游戏设计师/主程序/艺术总监/音频总监等 +- 执行专家:覆盖程序/设计/美术音频/叙事/运营质保 +- 引擎专家:Godot 4/Unity/Unreal Engine 5 + +**AI辅助游戏设计心得:** +> "Claude Code像一个思维催化器,用结构化问题拆解模糊想法;像拼图助手,快速试遍所有组合;像逻辑校验器,检查漏洞和矛盾。" + +**Spine+AI工作流探索:** +- T-pose角色图生成 → VLM定位部位 → SAM2精细分割 → Mask后处理 +- 6部位切分:头/身体/左臂/右臂/左腿/右腿 +- 调试经验:左右腿宽度差超阈值时的对称展宽问题 + +--- + +### 2.7 黄静雯 — 产品策略与game-analyst-agent + +#### 日报时间线 + +| 日期 | 核心主题 | +|------|---------| +| 5.22 | game-analyst-agent优化:修信息采集/视觉识别bug链 + 多模型并行辩论 | +| 5.25 | 《我的花园世界》产品机制研究:报告定位反思 + 叫我万岁爷对比 | + +#### 核心洞察 + +**研究报告的务实反思:** +> "研究报告不能替代项目管理。报告能回答'为什么值得做',但不能回答'谁负责、何时看结果、什么情况下转向'。" + +**game-analyst-agent:** +- 多模型并行辩论加速思考实践 +- 修两条关于信息采集及模型视觉识别的bug链 + +--- + +## 三、团队协作全景图 + +``` + ┌─────────────────────────────────────────────┐ + │ 钉钉群(每日日报分享) │ + └────────────────────┬────────────────────────┘ + │ + ┌────────────────────────────────┼────────────────────────────────┐ + │ │ │ + ┌─────▼──────┐ ┌────────▼────────┐ ┌────────▼────────┐ + │ 厦门点触科技 │ │ 深圳研究部 │ │ 用户306954 │ + │ 陈楚真/黄静雯 │ │ 夏莲/莫润麟/胡辉俊 │ │ 张家振 │ + └─────┬──────┘ └────────┬────────┘ └────────┬────────┘ + │ │ │ + SLG生态分析 学术研究+AI美术 AI+Spine+策划 + 私服/公会/留存 平台治理/综合投入 游戏设计/动画 + game-analyst-agent 峰值策略/博弈论 Claude Code Studios + │ │ │ + └────────────────────────────────┼────────────────────────────────┘ + │ + ┌──────────▼──────────┐ + │ 汪季(AI游戏开发) │ + │ 元素合成守卫 从0到1 │ + │ AI工具链/方法论沉淀 │ + └─────────────────────┘ +``` + +--- + +## 四、高价值知识资产清单 + +### A. 方法论级(可直接复用) + +| # | 资产 | 来源 | 适用场景 | +|---|------|------|---------| +| 1 | AI对抗式方案收敛法(V1→V5) | 汪季 | 任何需要方案决策的场景 | +| 2 | AI游戏8大工程基座 | 汪季 | AI驱动项目基础设施规划 | +| 3 | Claude Code Game Studios(49智能体) | 张家振 | 个人开发者用AI做游戏 | +| 4 | AI像素美术完整工作流(Fake Pixel) | 胡辉俊 | AI生成游戏资产 | +| 5 | 多模型并行辩论加速思考 | 黄静雯 | 利用AI进行决策 | + +### B. 理论级(有深度的分析框架) + +| # | 资产 | 来源 | 核心内容 | +|---|------|------|---------| +| 6 | SLG私服爆发模型 | 陈楚真 | 运营节奏×源码泄露×黑产专业化的三因素模型 | +| 7 | 《花园世界》留存设计拆解 | 陈楚真 | 节奏驯化+永动机制+公会KPI系统 | +| 8 | 综合投入变量框架 | 夏莲 | x_it = α·K + (1-α)·L 七机制解释变量体系 | +| 9 | 峰值策略数值模拟 | 莫润麟 | Real Options + Monte Carlo在游戏经营中的应用 | +| 10 | 企业竞争优势论 | 会议纪要 | "创造优势,不只是满足需求" | + +### C. 实践级(可操作的技术方案) + +| # | 资产 | 来源 | 核心内容 | +|---|------|------|---------| +| 11 | Spine+AI半自动工作流 | 张家振 | VLM定位+SAM2分割+Mask后处理 | +| 12 | AI游戏项目多窗口并行协作 | 汪季 | 主窗口压缩→子窗口分组→汇总 | +| 13 | 研究报告≠项目管理 | 黄静雯 | 战略研究必须推进到"谁负责/何时看结果" | +| 14 | Block AI前置预判 | 胡辉俊 | AI模拟→预筛→再进真实A/B测试 | +| 15 | 飞书→Obsidian知识库 | 莫润麟 | 文档持久化和知识管理 | + +--- + +## 五、团队核心关注的游戏产品 + +| 游戏 | 谁在分析 | 分析角度 | +|------|---------|---------| +| 《三国:谋定天下》 | 陈楚真/夏莲/莫润麟 | SLG设计、私服生态、竞赛机制、联盟治理 | +| 《我的花园世界》 | 陈楚真/黄静雯 | 留存设计、公会系统、产品机制 | +| 《Block Blast》 | 胡辉俊 | 虚拟玩家系统、AI行为模拟 | +| 《元素合成守卫》 | 汪季/张家振 | AI从0到1设计、灰盒MVP | +| 《塔防+建造》 | 张家振 | AI辅助策划、浮桥造路+炮塔设计 | +| 《三国:冰河时代》 | 黄静雯 | 产品体验与对比 | + +--- + +## 六、数据统计 + +| 维度 | 数量 | +|------|------| +| 分析的链接总数 | 33条 | +| 成功读取正文的文档 | 27篇 | +| 需要登录无法读取 | 4篇(胡辉俊2篇、陈楚真1篇、黄静雯1文件) | +| 汪季已读(lark-cli) | 6篇 | +| 读取正文合计 | 约 8万字 | + +### 无法读取的文档 +| 分享者 | URL | 原因 | +|--------|-----|------| +| 胡辉俊 | fcnlycv6dd0w/docx/NnBBdPLZZo... | 需要登录(无公开访问) | +| 胡辉俊 | fcnlycv6dd0w/docx/NBfLdojWgo... | 需要登录(无公开访问) | +| 陈楚真 | dianchukeji/wiki/E2HawE4f1... | 需要登录(无公开访问) | +| 黄静雯 | 文件附件 | 无法通过URL访问 | + +--- + +## 七、总结 + +**这是一个深度使用 AI 工具的跨公司游戏行业研究团队**。团队成员虽然分布在不同公司/租户,但围绕游戏行业的 AI 应用形成了高度协同的研究网络。 + +**团队最大的独特性:** 不是在"讨论AI能做什么",而是在"用AI实际做出东西": +- 汪季在做 IAA 手游灰盒 MVP +- 张家振在做 AI+Spine 动画生产链 +- 胡辉俊在做 AI 像素美术工作流 +- 夏莲/莫润麟在做学术研究的 AI 辅助 +- 黄静雯在做 game-analyst-agent + +**关键转变:** 从5.23的会议纪要中可以看出,团队正在从"技术探索"转向"业务有效性"验证——AI的价值不在于技术先进性,而在于能否进入项目生产链条解决实际问题。 \ No newline at end of file diff --git a/output/reports/full_summary_report.md b/output/reports/full_summary_report.md new file mode 100644 index 0000000..ea47bd6 --- /dev/null +++ b/output/reports/full_summary_report.md @@ -0,0 +1,827 @@ +# 飞书文档全面汇总报告 + +**生成时间**: 2026-06-02 11:40 +**文档总数**: 113 篇 + +## 一、总体统计 + +### 按群组 +| 群组 | 文档数 | +|------|--------| +| 创新组 | 67 | +| dc战略问题研究院 | 46 | + +### 按作者 +| 作者 | 文档数 | 所属群组 | +|------|--------|----------| +| 王雨默 | 20 | 创新组 | +| 韦译 | 18 | 创新组 | +| 刘鹏 | 12 | 创新组 | +| 卓泽 | 11 | 创新组 | +| 夏莲 | 10 | dc战略问题研究院 | +| 张家振 | 8 | dc战略问题研究院 | +| 胡辉俊 | 7 | dc战略问题研究院 | +| 莫润麟 | 7 | dc战略问题研究院 | +| 陈楚真 | 7 | dc战略问题研究院 | +| 黄静雯 | 7 | dc战略问题研究院 | +| 徐锐 | 6 | 创新组 | + +## 二、创新组文档详情 + +共 67 篇文档 + +### 王雨默 (2026-06-02 03:15:57) +链接: https://dianchukeji.feishu.cn/wiki/FYKlwX7D5ibbmSkaVMucgKAWnOe + +> 日报-王雨默输入“/”快速插入内容2026.6.1-日报-王雨默​用户2965用户2965今天修改一.工作内容概述​•使用 AI 分析《佛系消消消》的资源分包加载机制,结合本地缓存、运行日志和 Addressables catalog 文件,解析出关卡分包对应的 CDN bundle 地址,批量拉取主线 33 个关卡资源包并完成解包解析,提取主线普通关卡 3296 关,连同双牛模式、方块模式,总计整理 4452 关独立关卡数据。​•优化关卡生成器逻辑,提升其产出交付合规关卡的稳定性​•参与AI游戏开发交流会​二.《佛系消消消》关卡数据提取​利用AI对手机本地的《佛系消消消》包体资源进行了逆向分析和提取,目标是获取游戏中的完整关卡数据,并理解其关卡文件组织方式和加载逻辑。​前期已经通过解包确认,主包中只内置了第一批关卡LevelPart01,后续LevelPart02-33并没有直接存在于本地包体中。后续继续通过逆向解包、日志分析、本地缓存检查和 catalog 解析的方式,最终整理出游戏远程关卡分包的真实下载链路。​1.试错过程概述​一开始尝试从几个方向直接查找关卡数据:​•逆向解包主 + +--- + +### 刘鹏 (2026-06-01 22:44:23) +链接: https://dianchukeji.feishu.cn/wiki/PY6mwULmXiWbhEkpO3wcYjPCnrh + +> 日报-刘鹏输入“/”快速插入内容2026.06.01日报-刘鹏​用户2416用户2416昨天修改一、工作概述​1.数值调研启动​2.对后续任务进行重新规划​3.优化了一下UI编辑​二、主要产出​2.1-数值调研启动​1.调研以剧情阶段为节点,记录对应的订单、棋盘空间、生成器状态如何变化?​2.量化订单的需求物品和产出、剧情的金币需求和产出、棋盘空间的格子状态、当前物品链的等级解锁状态以及生成器当前的等级和产出​3.汇总分析:最后将这些数据汇总,让AI读取分析,同时会尝试去找现成的二合数值模板,结合起来参考分析,与AI商定数值框架,并进行标准数据测试、跑测等检测实现效果,并根据结果进行调整,直到数据测试达标、实际跑测体验达标。​订单表​25%剧情表​25%棋盘空间表​25%生产器表​25%2.2-对后续任务进行重新规划​重新明确两周后以项目上线为具体目标,与AI商讨调整的具体方案细节,具体化量化每天的产出目标。​1.剧情系统你想要做到哪一档:有章节推进、角色对话、阶段目标、若干关键剧情节点​2.基础功能系统需囊括:设置系统、存档系统、公告、账号登录​3.美术范围做到哪一层:具体的美术需求 + +--- + +### 韦译 (2026-06-01 22:44:11) +链接: https://dianchukeji.feishu.cn/wiki/PuiOw5HETi9pnekp6wlctOIvn0c + +> 日报-韦译输入“/”快速插入内容260601日报-韦译​用户6299用户6299昨天修改1.工作内容概述​1.参与AI游戏开发问题交流会,整理笔记和收获​2.调研拆解《浪漫餐厅》的关卡设计和数值设计规律:今天主要拆解了前15单的一个棋盘摆放规律​3.基础功能线——修复bug:点击生成器生成物品后,图标会错位的问题​4.商业化线——学习cocos UI多分辨率适配方法,完成多分辨率的初版开发​5.调研二合类游戏的数值模型​2.进度​2.1 参与AI游戏开发问题交流会,整理笔记和收获​2.1.1 AI配表问题​▪设计具体数值和表格字段​•设计的时候,可以跟AI来讨论数值设计。​•人管数值大方向和体验,AI来输出具体的数值​▪配表部分配表部分​•核心:配表的时候,重点是确定性,AI不能出一点错误,出错问题很大​•方法​◦方法一(较为稳健):AI出具体数值,人来配置,AI来检查​◦方法二:如果要AI来配,要保证准确性为100%​▪让AI用脚本来写入,不能直接填​▪原因:脚本是规范化程序,如果配得有问题,能够直接报错原因​▪不要让AI来配置表格的原因​•自己不去配表,全让AI配,整个表就是黑盒, + +--- + +### 王雨默 (2026-05-29 23:22:06) +链接: https://dianchukeji.feishu.cn/wiki/EIWNwKjnIipmStkzIr1cd1kTnPf + +> 日报-王雨默输入“/”快速插入内容2026.5.29-日报-王雨默​用户2965用户29655月29日修改一.工作内容概述​•尝试优化AI自动化关卡生成逻辑​•尝试优化自动化关卡截图分析流程​•体验《佛系消消消》,补充收集部分关卡样本,作为后续分析参考。​二.关卡生成逻辑优化​1.目前关卡生成痛点​目前关卡生成的主要问题集中在高维度关卡,尤其是10x10、12x12这类关卡。​之前的生成方式更偏向先随机生成区域,再通过反复尝试来筛选合适结果。这种方式在低维度关卡上还可以接受,但在高维度关卡上会暴露出几个问题:​•很多关卡虽然能生成出来,但并不是唯一解;​•有些关卡看起来结构正常,但玩家实际推理时可能无法稳定解出;​•通过随机微调区域边界来修复多解问题,成功率很低;​•部分备用生成路径虽然能产出关卡,但质量不可控,不适合作为正式发布内容;​•原本的难度评估比较粗,只能大致判断关卡是否可解,不能很好反映推理过程到底有多复杂。​也就是说,当前关卡生成的核心问题不是“能不能生成出来”,而是生成出来的关卡是否满足正式发布要求:​•答案是否唯一;​•是否能通过逻辑推理解出;​•难度是否符合预期;​ + +--- + +### 刘鹏 (2026-05-29 21:27:07) +链接: https://dianchukeji.feishu.cn/wiki/G5cPwiVSUiGzkrk2ZIzcP24hn0b + +> 日报-刘鹏输入“/”快速插入内容2026.05.29日报-刘鹏​用户2416用户2416昨天修改一、工作概述​1.优化拓展UI编辑器功能​2.同步优化UI风格和素材​​二、主要产出​2.1-UI编辑器优化​2.1.1-修复配置缓存失效问题​•问题:编辑器导出参数后,运行 Play Mode 或重新打开编辑器场景时,部分UI 布局没有变化​•原因:参数不匹配,在调整功能/新增UIicon等操作时,AI会为相应的功能和Icon做配置适配,这时会调整底层的配置,有时会修改名称/配置路径导致在UI编辑器界面读取时会存在功能性错位,从而使得布局没有正常加载​•方案:UIConfig.cs添加[InitializeOnEnterPlayMode]重置静态缓存;BuildInScene()开头调用UIConfig.Reload()确保读取最新配置。同时在功能制作的workflow节点添加UI编辑器功能同步节点,快速修复UI的功能性错位。​2.1.2-新增 Sprite/Icon 路径导出​•问题:编辑器只导出布局参数(位置、大小),更换 Image 组件的 sprite 后不会写入配置​•方案:新增 + +--- + +### 韦译 (2026-05-29 21:01:23) +链接: https://dianchukeji.feishu.cn/wiki/N4MdwTuQAiPyGRkHWJPcuyeInpf + +> 日报-韦译输入“/”快速插入内容260529日报-韦译​用户6299用户6299昨天修改1.工作内容概述​1.基础功能线——使用自动化批量关卡生成方案,复刻《庄园合合》的关卡:目前能够完整复刻前15个订单,以及部分棋盘的物品摆放​2.基础功能线——给自动化批量关卡生成方案,做了一个skill来一键启动​3.基础功能线——增加调试面板​4.基础功能线:关于生成器和物品的一些新功能​a.完成剧情节点时,除了经验,还会发放物品/生成器奖励,发放的奖励会进入新增按钮​b.达到第五等级的生成器,能够生成副链的物品​5.商业化线——完成新手引导流程的开发​6.美术线——继续生成新增物品链条的美术资源​7.美术线——每日UI审美提升训练​2.进度​2.1 基础功能线——使用自动化批量关卡生成方案,复刻《庄园合合》的关卡:目前能够完整复刻前15个订单,以及部分棋盘的物品摆放​◦参考昨天调研的结果,将生成器、物品一一映射到本项目中​◦目前效果对比《庄园合合》​▪复刻了订单相关的数值,例如订单物品、订单奖励的金币​▪还原部分棋盘上物品的摆放位置(还有部分还没解锁)​▪复刻新手引导教程​2.2 基础功能线— + +--- + +### 王雨默 (2026-05-29 00:09:28) +链接: https://dianchukeji.feishu.cn/wiki/BGn2w5h1Vi8LVWkSzwbcp4xKnNf + +> 日报-王雨默输入“/”快速插入内容2026.5.28-日报-王雨默​用户2965用户29655月29日修改一.工作内容概述​•优化棋盘交互体验、优化提示系统逻辑​•修复广告按钮可以快速点击、重复发送广告请求的问题​•尝试使用 AI 调用现有关卡生成器 API,初步验证 AI 是否能够自动调用项目工具,并按照预设目标控制关卡难度曲线​•收集《佛系消消消》部分关卡数据,尝试使用 AI 对其进行结构化整理与分析,初步验证 AI 辅助分析外部关卡设计的可行性​​二.AI生成关卡尝试​尝试使用 AI 调用现有的关卡生成器 API,进行自动生成关卡的初步测试。本次测试的重点并不是单纯追求最终生成多少可用关卡,而是验证 AI 是否能够理解并调用项目中已有的工具链,包括生成器参数配置、批量生成、结果校验、状态流转和资源导出等流程。​测试中,初步以 50 关为目标进行生成尝试,并按照预设的难度曲线进行规划。整体设计思路是每 5 关作为一个小波次,通过“逐步爬坡 + 阶段卡点”的方式,让关卡难度在前期逐步上升,同时在固定节点提供一定挑战。通过这种方式,可以初步验证 AI 是否能够不只是机械调用生成接口,而 + +--- + +### 韦译 (2026-05-28 22:39:42) +链接: https://dianchukeji.feishu.cn/wiki/FVJ6w0RZFirH9tk7uA4ctqQTn1d + +> 日报-韦译输入“/”快速插入内容260528日报-韦译​用户6299用户62995月28日修改1.工作内容概述​1.基础功能线——完善自动化批量关卡生成方案:目前能够跑通从关卡设计和数值设计开始,到AI配置的整个闭环​2.基础功能线——调研竞品《庄园合合》的关卡设计和数值设计:工作量比较大,预计还需要1天完成​3.基础功能线——根据目前调研出来的《庄园合合》的关卡和数值,使用自动化批量关卡生成方案,复刻到当前游戏中:目前遇到一些小bug,预计明日完成​4.基础功能线——新增物品合成链,满足游玩内容扩充的需求​5.基础功能线——新增生成器合并功能(之前不能合并)​6.美术线——生成新的物品合成链的美术资源​7.美术线——每日UI审美积累​2.进度​2.1 完善自动化批量关卡生成方案​◦新增了规则层自动落表功能:规则不再默认靠人工手写,改成由 AI 根据讨论结果生成规则层 YAML /配置,再交给算法校验。​◦新增了 chapter skeleton 自动生成功能:章节骨架不再要求人工先写,改成 AI 先生成章节骨架,再往下展开关卡。​◦新增了 slice 批量生成功能:AI 按章节骨架批 + +--- + +### 刘鹏 (2026-05-28 22:30:28) +链接: https://dianchukeji.feishu.cn/wiki/HVxhwFfM2idMx7kTiuBcgVBXnCb + +> 日报-刘鹏输入“/”快速插入内容2026.05.28日报-刘鹏​用户2416用户24165月28日修改一、工作概述​1.完成UI编辑器细调功能​2.对现有订单、棋盘的UI和功能逻辑进行优化​3.优化了一下体验阶段参数生成器的流程逻辑​​二、主要产出​2.1-完成UI编辑器细调功能​2.1.1-开发目的​最后的百米冲刺:在早期使用AI完成UI布局时,发现AI能够通过识别草图/详细的描述来完成80%的UI布局,剩下的20%,要么需要非常精确的原型图,要么存在自然语言难以描述或描述困难繁琐的情况,例如单个订单的UI就包括人物icon、物品栏背景、物品格子、物品、提交按钮、奖励面板、奖励icon以及奖励数量等这些UI元素的位置、缩放和逻辑。纯使用自然语言或原型图来完成会比较费时间,且后续调整的时间成本也比较高,最快的办法自然是自己上手直接调,所以会选择制作这样一个功能,来完成细节的调整​2.1.2-主要功能​1.编辑调整:在 Unity 编辑模式下,借助Unity编辑器本身的UI调整功能,对视图窗口中的UI组件进行缩放、拖动等,直接把游戏里的整套 UI 搭出来。​2.快速配置:UI搭好后,可快 + +--- + +### 王雨默 (2026-05-28 01:20:32) +链接: https://dianchukeji.feishu.cn/wiki/Hv4uwS6U9iqN1skMIKIczOgAnKb + +> 日报-王雨默输入“/”快速插入内容2026.5.27-日报-王雨默​用户2965用户29655月28日修改一.工作内容概述​•基本完成项目主要系统界面的多分辨率适配逻辑梳理与落地调整。​•尝试使用 OpenClaw 自动收集整理抖音平台上《佛系消消消》的关卡数据,并验证视频反向提取方案的可行性。​​二.多分辨率适配相关​经过一天的尝试、排查和反复验证,基本完成了当前项目各主要系统的 UI 适配逻辑梳理,包括局内界面、主菜单、碎片收集面板、结算弹窗、通用弹窗、背景层以及部分特殊交互节点的适配处理。​本次适配工作的重点不只是修复单个界面的显示问题,而是对项目整体 UI 结构进行了一次重新整理。由于早期 UI 制作阶段没有针对多分辨率适配制定统一层级规范,部分界面中背景、内容、按钮、弹窗、交互区域混在同一套节点层级中,导致后续适配时容易出现互相影响的问题。​因此今日在实际试错的基础上,基本完成主要系统的适配逻辑梳理与落地调整,并总结出一套后续可以继续沿用的 UI 层级规范和适配思路。​​1.最终确定的 UI 层级规范与适配思路​当前阶段确定的整体原则是:背景独立处理,内容按区域分组,交互节点 + +--- + +### 刘鹏 (2026-05-27 22:05:15) +链接: https://dianchukeji.feishu.cn/wiki/Qn6Cw8OgmiBohUkweYCcPnLpnLb + +> 日报-刘鹏输入“/”快速插入内容2026.05.27日报-刘鹏​用户2416用户24165月27日修改一、工作概述​1.完成新手三步引导系统和单元测试系统​2.完成AI根据需求生成阶段性体验参数工作流​二、主要产出​2.1-完成新手三步引导系统和单元测试系统​使用workflow跑了一下昨天与AI一同设计的并行功能开发的工作流,同时去实现新手引导系统和单元测试系统。​1.使用差异:​•节点确认:会按照脚本在固定的节点进行预设询问,而不是让claude自行决定是否要询问你,询问哪些内容。​•分支逻辑:可运行单独的分支循环,例如“新手引导系统“进行到功能验收时会固定进行询问预设的选项,修复后也会再次询问直到最终通过。​2.最终测试结论:​•稳定性与智能牺牲:workflow通过脚本约束claude,以让AI完成稳定的工作产出,这个过程会牺牲掉部分AI的智能,也会存在工作流出问题以后,AI不会自行调整的问题。所以整体上是往稳定工作流方向专精的工作模式,应用场景比较有限。​•固有限制:workflow只会在会话开始时执行一次,后续产生上下文压缩以后,会直接遗忘当前节点转为普通对话,因此需要进行 + +--- + +### 韦译 (2026-05-27 22:01:25) +链接: https://dianchukeji.feishu.cn/wiki/Xd60wq12vi5tAUkx1NmcZdE4nrc + +> 日报-韦译输入“/”快速插入内容260527日报-韦译​用户6299用户62995月28日修改1.工作内容概述​1.基础功能线——实现自动化批量关卡生成方案的完整流程:目前能够完成跑通关卡自动生成的流程,每个流程步骤都可以追溯​2.基础功能线——优化UI:​a.优化了局外主界面的UI和局内游戏界面的UI。参考《浪漫餐厅》,去除了多余的信息​b.给关键UI信息、功能按钮生成了统一的美术资源底图​3.美术线——针对提升UI审美,搜集了一些UI设计网站,后续进行针对性地审美提升练习​4.整理出了问题清单​2.进度​2.1 实现自动化批量关卡生成方案的完整流程​◦当前的进度:目前能够完成跑通关卡自动生成的流程,每个流程步骤都可以追溯​👍•关卡自动生成的流程​第一步:人工与 AI 讨论规则层目标和体验原则​第二步:AI 写规则层配置,算法自动校验与编译​第三步:人工与 AI 讨论章节体验方向​第四步:AI 拆解每一章为多个小关卡(slice),并配置好关卡数值​第五步:算法校验、打报告、过滤不合格项​第六步:AI 根据错误与报告自动修复​第七步:人工查看数值、说明、风险报告,并进入试玩验收​🥥目 + +--- + +### 王雨默 (2026-05-27 00:30:53) +链接: https://dianchukeji.feishu.cn/wiki/Y42iwXAsXigSyfkF6bXc5UkLnyb + +> 日报-王雨默输入“/”快速插入内容2026.5.26-日报-王雨默​用户2965用户29655月27日修改一.工作内容概述​•产出剩余系统所需美术资源,并完成项目内替换​•学习 Cocos 多分辨率适配方法,理解 Canvas、Widget、UITransform 等相关组件的作用,并初步对部分界面尝试进行适配调整。​​二.多分辨率适配知识梳理​1.多分辨率适配原理思路​多分辨率适配并不是单纯地把 UI 等比例缩放到不同屏幕上,而是要在不同设备宽高比下,保证核心内容可见、界面布局稳定、交互区域合理,并尽量避免 UI 被裁切、留黑边或位置错乱的问题。​Cocos 中多分辨率适配的核心,可以理解为“以设计分辨率为基准,在真实设备屏幕上重新映射显示区域”。​设计分辨率相当于开发时使用的一套标准画布尺寸,例如按照1080×1920来搭建界面。但在不同的设备下,屏幕分辨率和宽高比并不总会保持统一,因此运行时需要根据设备屏幕尺寸,对 UI 进行缩放与布局调整。​Cocos 的 Canvas 会基于设计分辨率和当前设备屏幕尺寸,计算 UI 在真实屏幕中的显示区域与缩放关系。​适配中比较关键的是 Fi + +--- + +### 刘鹏 (2026-05-26 22:30:51) +链接: https://dianchukeji.feishu.cn/wiki/CDoOwO5ppif43Ak6Lx9cWGMensf + +> 日报-刘鹏输入“/”快速插入内容2026.05.26日报-刘鹏​用户2416用户24165月26日修改一、 工作概述:​1.对项目进行打包,在开发者工具上测试广告系统​2.完成测试埋点,并能够正常接入Game Analytics平台进行数据同步​3.探索新的AI agent工作模式——WorkFlow​二、主要产出​2.1-项目打包与广告系统测试​目前已完成项目打包,并在微信开发者平台完成了项目运行测试​测试结果:​1.项目可正常完成微信小游戏的转包,并且可在开发者平台正常运行​2.可正常完成广告播放(真实广告需要后续接入广告位测试)和基础的玩法交互,无报错​3.UI存在适配问题,部分UI存在布局位置不对的情况,主要是引擎和测试机的分辨率存在差异,需要在引擎端做动态分辨率UI适配。​2.2-测试埋点与GA平台测试数据同步​核心实现​•7 个埋点事件:game_start、merge_success、order_complete、ad_trigger、ad_complete、generator_click、session_end​•Provider 架构:IAnalyticsProvid + +--- + +### 韦译 (2026-05-26 22:09:01) +链接: https://dianchukeji.feishu.cn/wiki/SuymwQjFYimgnRkZRePcIW0PnWe + +> 日报-韦译输入“/”快速插入内容260526日报-韦译​用户6299用户62995月26日修改1.工作内容概述​1.基础功能线:完成UI的重构,总结了踩坑经验​2.基础功能线:实现关卡剧情推进​3.基础功能线:实现自动化批量关卡生成方案的部分,目前能够生成第一批关卡进行游玩​4.商业化线——接入数据埋点:熟悉并且理清了GameAnalytics平台的操作流程,能够把接入的事件埋点展示成可视化图表​2.进度​2.1 完成UI的重构,总结了踩坑经验​2.2 实现关卡剧情任务推进​◦目前实现的功能​▪可配置剧情任务​▪玩家可消耗金币完成剧情任务,获得奖励(目前奖励暂时配置的是经验,后续会配置物品和合成器)​▪可以在局内主场景中点击剧情按钮触发,也可以在主界面点击剧情任务触发​2.3 实现自动化批量关卡生成方案的部分,目前能够生成第一批关卡进行游玩​以下这方案是怎么自动化批量生成的​◦3个核心概念:​▪《浪漫餐厅》的长关卡主棋盘​•玩家始终在同一张主棋盘上玩,不切棋盘,不是一关一关地跳。变化发生在“这一阶段让玩家做什么、解锁什么、承受什么压力”————所以不能按照传统的关卡制度来划分关卡,而应 + +--- + +### 王雨默 (2026-05-26 00:17:36) +链接: https://dianchukeji.feishu.cn/wiki/Mx4SwTP4HiQNISkrygQcGk9jnIe + +> 日报-王雨默输入“/”快速插入内容2026.5.25-日报-王雨默​用户2965用户29655月26日修改一.工作内容概述​•皮肤面板、碎片收集面板UI美术资源产出、替换​•修复替换过程发现的一些缺陷与bug​•了解Claude Code Workflow功能,并尝试用其进行完整的项目代码审查、修改、验证任务。​​二.Claude Code Workflow 相关​1.概念​Claude Code Workflow 是 Claude Code 最近更新的一种面向复杂开发任务的流程化执行方式。它通过阶段拆解、任务委托、能力复用和验证闭环,将 Claude Code 从“单次回答问题”扩展为“持续推进任务”的开发协作模式。对于代码审查、项目整改、批量重构、测试补充、自动化验证等任务,Workflow 能够提供更清晰的执行路径和更稳定的过程控制。​2.启用方式​1.确保Claude Code版本大于等于v2.1.147​2.终端命令行输入:​◦macOS / Linux / WSL / Git Bash:export CLAUDE_CODE_WORKFLOWS=1​◦Windows CMD: + +--- + +### 韦译 (2026-05-25 22:30:17) +链接: https://dianchukeji.feishu.cn/wiki/HuUIwA39fi3UsqkdfhTcE9hRnde + +> 工作内容概述​1.修复UI严重卡住开发进度:今天使用Claude修改UI,但是错误很多,严重拖延了今天的开发进度,对此进行了一波反思​2.自动化批量关卡生成方案较为复杂,今天仍然在跟AI讨论。预计明天进行实现,生成第一批关卡​3.基础功能线:完成体力限制的生成器生成机制​4.基础功能线:新增动画——完成订单时,订单缩小并退出​2.进度​2.1 修复UI严重卡住开发进度​◦修复情况:​▪今天把原来的棋盘从7x7修改为7x9,对标浪漫餐厅。​▪但是棋盘变高,超出了原有大小。所以我希望对棋盘的位置进行微调,但是棋盘格子无法在编辑器的预览界面中进行预览。​▪于是我让Claude在编辑器预览中,新增棋盘格子节点,绑定游戏内的棋盘格子。但是效果很差。​•棋盘格子的美术样式跟之前的相比,差距很大,不美观​•同时claude修改后,bug非常多,整个游戏无法进行游玩。经常是改了A就会出现B,改了B就会出现C。整体开发效率非常低。​ + +--- + +### 刘鹏 (2026-05-25 22:29:38) +链接: https://dianchukeji.feishu.cn/wiki/KoXGwnkJaiO7q8kah6WcAGmvn0l + +> 日报-刘鹏输入“/”快速插入内容2026.05.25日报-刘鹏​用户2416用户24165月26日修改一、工作概述​1.在原型图UI框架基础上尝试导入包装素材进行UI配置测试​2.完成合并的反馈的效果优化以及订单列表滑动显示功能​3.完成项目接入广告的功能实现和验证​二、主要产出​2.1-导入包装素材进行UI配置测试​在完成基础原型图的基础上,尝试导入UI素材,并让claude自行按照ID对应界面中已经存在的UI进行配置,精确度在90%以上,主要受到命名规则的影响,以及素材ID和UI的ID数量是否一一对应。​2.1.1-以下是两种错误判定的具体情况:​1.素材ID和组件ID无联系/联系较弱,例如:素材命名为board,但组件中存在多个board,例如cell_board、order_board等,则AI极大可能无法进行精确配置​2.素材ID和UI的ID数量不是一一对应的,例如UI组件有一个character配置,但素材中有多个character,可能出现配置错误,多个UI组件对应少量素材配置时,只要名称对应,通常不会有错。​2.2.2-避免方法:​1.精确命名,在Schema中统一好命 + +--- + +### 王雨默 (2026-05-23 00:57:23) +链接: https://dianchukeji.feishu.cn/wiki/Bf4mwuFU9in51RksjDDc5Fdgnag + +> 日报-王雨默输入“/”快速插入内容2026.5.22-日报-王雨默​用户2965用户29655月23日修改一.工作内容概述​•参与工作流分享汇报​•继续产出UI资产,完善局内界面美术表现,已完成各模式玩法局内主界面的资产替换,以及棋盘单元格资源替换;​•同步优化细节表现,增加单元格交互震动功能​​二.通用性资源生成与九宫格复用尝试​在继续产出局内 UI 资产的过程中,发现部分按钮、底板类资源存在尺寸相近、风格相似的问题,浪费空间,因此开始尝试将这类素材抽象为通用底板资源。​核心思路是:​•尽量去除强绑定内容,比如复杂纹路图案、不可复用装饰等;​•保留通用的边框、底色、材质等;​•可以通过九宫格拉伸适配不同尺寸;​•让同一张资源可以应用到按钮、面板、棋盘单元格或其他 UI 容器中。​这样做的好处比较明确:一方面可以提升资源复用率,减少不同尺寸、不同场景下重复生成相似资源的情况;另一方面也能降低包体大小压力,避免大量近似 UI 资源同时进入项目。​​​三.Codex 内置生图工具的小规模角色资产测试​尝试使用 Codex 内置生图能力进行角色类资产绘制,主要测试方向是小规模角色资产的生成效 + +--- + +### 韦译 (2026-05-22 22:39:12) +链接: https://dianchukeji.feishu.cn/wiki/DcOkwuOj6iPvdWkaFD1clKuRnAB + +> 工作内容概述​1.基础功能线——完成w2要求的初版关卡和数值设计,玩家能够正常游玩前20个订单​2.基础功能线——研究自动化批量关卡生成方案​3.商业化线—— 广告接入:尝试在开发者工具中进行广告测试,但是遇到资格问题​4.商业化线——接入数据埋点:跑通了游戏数据分析平台 GameAnalytics的流程,大部分埋点成功生效并显示​5.基础功能线——按玩家成长进度解锁生成器,通过新增按钮添加生成器到棋盘中​6.在接入微信开发者工具时测试广告时,发现切换分辨率后,UI会乱。调查后发现是之前的UI开发不规范导致的,目前正在重构UI​2.进度​2.1 基础功能线——完成w2要求的初版关卡和数值设计,玩家能够正常游玩前20个订单​◦根据w2-1要求的数值,设计了一批初始的订单,难度逐步提升​◦同时,后续新增了根据玩家进度解锁新的生成器的功能,整个玩法循环初步建立起来​▪通过二合交付订单——>金币增长——>解锁新的生成器——>解锁新的物品链,能够二合新的物品——>能够交付高难度的订单​2.2 基础功能线——研究自动化批量关卡生成方案​◦跟AI讨论了比较长的时间,主要从以下几个需求来设计整个方案​ + +--- + +### 刘鹏 (2026-05-22 22:29:44) +链接: https://dianchukeji.feishu.cn/wiki/VCZAwd24fiQIHdk9nrdcKR9TnWg + +> 日报-刘鹏输入“/”快速插入内容2026.05.22日报-刘鹏​用户2416用户24165月22日修改一、工作概述​1.完成订单系统和美术的基础包装​2.借鉴同组成员的工作流,对自身的原工作流做调整​​二、主要产出​2.1-完成订单系统和基础包装​2.1.1-订单系统:​订单系统运作逻辑​数据层:一个订单长什么样​OrderData.cs 定义了订单结构:​核心逻辑:OrderManager 做了什么​OrderManager.cs 是单例,负责全部订单逻辑:​1. 初始化时订阅棋盘事件​代码块​Plain TextBoardEvents.OnMergeSuccess → 记录玩家最高合成等级​2. 检查是否能交付(CanFulfillOrder)​遍历棋盘所有格子,统计每种物品数量,对比订单所需 — 全部满足则可交付。​3. 提交订单(TrySubmitOrder)​代码块​Plain Text检查能否交付 → 从棋盘移除对应物品 → 发放金币/经验 → 标记完成 → 刷新新订单​UI层:OrderUI 做了什么​OrderUI.cs:​•最多显示3 个订单卡片​•每张卡片布局:左侧 + +--- + +### 徐锐 (2026-05-22 19:22:14) +链接: https://dianchukeji.feishu.cn/wiki/RIhawaIYwiBGHak7YAVcaSapnTe + +> 日报 徐锐输入“/”快速插入内容2026-05-22-日报 徐锐​用户2199用户21995月22日修改1. 工作内容概述​1.基础功能线——UI美术资源系统搭建——完成了UI美术资源管理系统的代码实现,建立自动化纹理加载框架​2.美术线——UI美术资源汇总表整理——输出了完整的UI美术资源需求清单(39项),按P0/P1/P2分级​3.探索新的AI工具——调研并测试了多款AI辅助开发工具,包括会议上其他同学提到的新的工作流等​4.美术AI生成探索——尝试使用AI工具生成游戏美术素材​2. 成果​2.1 基础功能线——UI美术资源管理系统搭建​背景:原有UI界面全部使用纯色 ColorRect + 文字占位,没有贴图资源管理机制,美术交付后需要大量手动改造。​实现方案:​模块​内容​UI资源汇总表​在《冰雪餐厅_美术资源汇总.xlsx》中新增"UI美术资源"Sheet,列出39项UI贴图需求,分为通用控件(common)、战斗界面(battle)、任务系统(task)、玩家信息(player)四大类,按P0/P1/P2优先级标注​UIAssets AutoLoad​创建scripts/ + +--- + +### 徐锐 (2026-05-22 11:00:22) +链接: https://dianchukeji.feishu.cn/wiki/SmxzwvhHOi0rk1kSXxmcMobGnGd + +> + +--- + +### 刘鹏 (2026-05-22 10:59:53) +链接: https://dianchukeji.feishu.cn/wiki/MObLwsaWoirykyke8NXcFUlhnfd + +> 工作进度总结-刘鹏输入“/”快速插入内容2026.05.22工作进度总结-刘鹏​用户2416用户24165月22日修改当前阶段完成的工作内容​后续工作计划​表格​​ + +--- + +### 韦译 (2026-05-22 10:57:59) +链接: https://dianchukeji.feishu.cn/wiki/YniYwtxAiiKqcmkmVM5clNxTnQf + +> 工作流文档输入“/”快速插入内容工作流文档​用户6299用户62995月22日修改​ + +--- + +### 王雨默 (2026-05-22 00:21:29) +链接: https://dianchukeji.feishu.cn/wiki/ZVOVw5BCriBcUfkT1cFcOw3nnBc + +> 日报-王雨默输入“/”快速插入内容2026.5.21-日报-王雨默​用户2965用户29655月22日修改一.工作内容概述​•使用生图工作流来产出美术资产,解决过程中遇到的问题​•完成主菜单美术资产产出,并在游戏内进行替换​•小功能点优化:补充关卡模式前期自动揭示逻辑、增加金币显示UI​•整理汇报内容​​二.生图工作流测试验证情况​今日主界面资源出图过程中暴露出多个问题,主要集中在复杂需求理解、图片尺寸控制和后处理质量上。​1.Agent Team 全自动流程仍无法应对复杂需求​原计划是通过 Agent Team 完成从需求分析、资源生成、拆分、后处理到入库的完整自动化流程。但实际执行中发现,当前流程在中间脚本调用、状态传递、工具接口使用等环节频繁出错。​比较明显的问题是:流程还没有真正进入高质量出图阶段,前置的脚本调用和任务编排就已经产生较多异常。这说明当前 Agent Team 流程的稳定性不足,如果继续强行推进全自动化,反而会放大试错成本。​因此今日将主流程调整为半自动逐模块流程,即:按模块拆分需求 → 单模块生成 → 人工确认 → 修正问题 → 后处理 → 入库​这种方式虽然自 + +--- + +### 韦译 (2026-05-21 23:13:47) +链接: https://dianchukeji.feishu.cn/wiki/AjK2wPpI7iOFo5kOImVcEe1WnNS + +> 工作内容概述​1.调研接入抖音/微信平台的方案​2.基础功能线——对已有系统的优化——优化棋盘和订单系统的一些bug​3.W2线——广告接入—— 用Mock模式跑通广告位的全流程(预计明日进入微信开发者工具进行测试)​4.完成了整个项目配置方案的设计和实现,其中的重点是物品链schema的设计与实现。能够帮助后续使用AI批量生成关卡、关卡数值​5.基本程序策划工作流文档的编写,还差一点收尾(预计明日早上完成2个工作流文档的编写)​2.进度​2.1 调研接入抖音/微信平台的方案​综合二合项目本身的特点和各个平台的优缺点,调研了几个方案,最终选择综合的方案C:先上线微信验证技术,然后针对抖音玩家和算法偏好进行新一轮的美术包装和视觉反馈设计,再上抖音​​关于项目选择抖音平台还是微信平台接入的调研选择​2.2 基础功能线——对已有系统的优化——优化棋盘和订单系统的一些bug​问题​修法​订单最多只能承接5单,这5单还都是随机生成的,没有固定订单系统的数值设计​​新增 configs-src/orders/main_20.yaml 和对应 schema,通过这些配置,能够规范设计最多20单的订单 + +--- + +### 刘鹏 (2026-05-21 22:35:51) +链接: https://dianchukeji.feishu.cn/wiki/F05nwzkQ0ioUxRkNaV8cEBvzn6b + +> 日报-刘鹏输入“/”快速插入内容2026.05.21日报-刘鹏​用户2416用户24165月22日修改一、工作概述​1.完成前两天的方法论和提示词梳理沉淀​2.进行棋盘模块、生成器模块和合并模块的功能开发​3.尝试icon的批量生成和UI的成套生成​二、主要产出​2.1-前两天工作过程中的提示词和方法论的沉淀梳理:​对前两天前期验证和调研过程中产出的方法论和提示词进行梳理​主要包含模块:方向调研、策划案生成、Schema生成、美术icon和UI生成​文档链接:​AI提示词和方法论沉淀​2.2-棋盘模块、生成器模块和合并模块的功能开发:​2.2.1配置数据层与数据加载​目前尝试AI配置的提示词偏向硬性指标向的,如生成器生成范围为1~2级,遮挡的物品数量占比要超过50%等,目标是快速获得一个贴近主流产品如四季合合的功能表现,明天会尝试在此基地上,通过目标/体验指向来看AI是否能根据体验区配置参数,同时还会设置一个对照组,例如一开始就让AI以体验为目标直接配置的参数,检测保底标准对最终效果的可能影响​运行后加载配置​2.2.2棋盘模块 (BoardController)​棋盘初始化:​•根据 + +--- + +### 徐锐 (2026-05-21 21:57:45) +链接: https://dianchukeji.feishu.cn/wiki/Qad6w4jY9iweK5kggeCcLkifnIN + +> 日报 徐锐输入“/”快速插入内容2026-05-21-日报 徐锐​用户2199用户21995月22日修改工作内容概述​1.项目系统完善与搭建:完成了游戏的基础循环,但在构建对话和建筑等级系统时遭遇了较大bug,只能先进行回退,后续再慢慢尝试。同时还初步导入了几个临时的图片素材进行测试,可以正常加载图片素材。​a.解决方法:后续将进一步拆分并细化对话系统与建筑等级系统的规则,将复杂功能拆解为多个独立模块,逐步描述并交由 AI 分阶段实现,以降低逻辑冲突与 Bug 出现概率。​2.游戏主题确定与素材生成尝试:初步决定使用冰雪餐厅作为主题,生成了一些图片,但一致性较差,让AI生成了一版提示语,后续再尝试生成​a.选择冰雪餐厅为主题的原因:一方面,《Whiteout Survival》等冰雪题材产品在海外市场热度较高,说明冰雪风格在用户审美与题材接受度上具备一定优势;另一方面,目前市面上的餐厅经营类游戏较少采用冰雪主题,因此希望通过“冰雪+餐厅经营”的结合做出一定差异化,在视觉氛围与题材方向上形成独特记忆点。​b.AI图片素材解决方法:后续将统一角色、场景、光影与配色等关键词描述,固定美术风格 + +--- + +### 韦译 (2026-05-21 01:13:40) +链接: https://dianchukeji.feishu.cn/wiki/JY56wsBHniMVP6k7y7scQ4gUnOg + +> 日报-韦译输入“/”快速插入内容260520日报-韦译​用户6299用户62995月21日修改1.工作内容概述​1.基础功能线——完成订单系统,包括2个小功能:订单交付按钮、对应物品的格子高亮​2.基础功能线——金币和钻石经济货币接入:配合订单系统需要,进行真实接入,不再使用假数据​3.W2线——广告接入​a.完成对广告接入的调研工作​b.目前正在用假数据尝试跑通触发广告的整个流程,预计明日能够跑通​4.美术线——UI优化:调整美化了订单系统的UI;对几个重要的按钮添加了icon图标​2.进度​2.1 基础功能线——完成订单系统​◦订单交付按钮:如果棋盘上凑够了订单所需物品,则此时在订单上显示完成按钮,玩家点击按钮后进行订单交付​◦对应物品的格子高亮:如果棋盘上的物品是订单所需的物品,则该物品的格子高亮,用于提示玩家​2.2 基础功能线——金币和钻石经济货币接入​◦接入真实金币和钻石数据,目前暂定经济货币绑定玩家的本地存档​◦每完成一件订单增加一定数量的金币,目前暂定每完成一件增加10货币​◦钻石目前还没做相关设计。开发成真实数据主要是为了购买额外奖励。​2.3 W2线——广告接入​◦ + +--- + +### 王雨默 (2026-05-21 01:06:56) +链接: https://dianchukeji.feishu.cn/wiki/FMV0w4C8ai0oJXkxzhFcygeqnQB + +> 日报-王雨默输入“/”快速插入内容2026.5.20-日报-王雨默​用户2965用户29655月21日修改一.工作内容概述​•搭建美术Agent Team,跑通多agent协作资产交付流程​•重新确认项目美术风格方向​​二.美术Agent Team搭建​当前项目在 UI 生图和资源交付过程中,已经不只是单纯生成效果图,而是逐步进入到“正式资产生产”的阶段。因此需要建立一套更稳定的多 Agent 协作流程,用来解决以下问题:​•正式资产交付​◦不只生成概念图或临时效果图,而是要能够输出可入库、可复用、可接入 Cocos 项目的资源文件。​◦资源需要经过切片、透明背景处理、命名规范、QC 检查等步骤,避免后续人工返工。​•控制美术风格统一性​◦之前单次生图容易出现风格漂移、细节不稳定、不同批次资源不一致的问题。​◦因此需要引入 art-director 角色,专门负责方向把控、概念审核和最终风格验收。​•支持后续功能拓展​◦除了生成图片资源,还需要配套完成资产管理、库存更新、配置文件生成等工作。​◦后续如果继续推进自动拼 UI Agent,也需要提前沉淀 layout JSON、资源清单、 + +--- + +### 刘鹏 (2026-05-20 21:45:20) +链接: https://dianchukeji.feishu.cn/wiki/IM5zwpPKUixJBUkninjccrl0njg + +> 日报-刘鹏输入“/”快速插入内容2026.05.20日报-刘鹏​用户2416用户24165月22日修改一、工作概述:​1.AI绘制游戏内物品图片和UI的工具链验证​2.落地实施方案的具体规划确定​3.Schema生成标准化、细化。​二、AI美术的工具链验证:​1.基础物品icon绘制:豆包AI绘制透明背景的多格icon整图——>Image Splitter进行分块切割​优点:工具无额外使用成本,出图快,风格可控(采用同一风格的参考图生成,风格的可控率在90%,细节上会有一点小变动)​可提升点:出图结果的有效性目前比较随机,保底70%,主要受物品的知名度和特征明显程度、参考图的质量以及提示词的描述细致程度影响。提升的方向为物品选择时尽量选有明显特征和高知名度的物品。提示词尽可能详细的描述物体(可以使用AI生成对应物品的提示词描述),若对物品准确性要求不高可适当粗略的描述物体来进行抽卡操作,逐步提取合适的物品。参考图也尽可能选取清晰风格统一的图片(例如对标产品的界面高清图)​豆包AI绘画提示词:​结合参考的风格生成一套以下物品icon整图:​玉石矿屑​原生玉原石​雕花玉簪​平安扣玉佩​和田 + +--- + +### 徐锐 (2026-05-20 19:41:35) +链接: https://dianchukeji.feishu.cn/wiki/AqzvwhCH9iKYfbkQ5iacMuKJnMe + +> 日报 徐锐输入“/”快速插入内容2026-05-20-日报 徐锐​用户2199用户21995月20日修改1.工作内容概述​1.美术AI工具调研与尝试:尝试了2D游戏素材生成,包括Holopix、Banana、SD等,生成了一批临时素材。​2.产品设计文档深化与临时配表:​◦检查并完善了昨日设计文档的初始框架。​◦针对二合(Merge)玩法的核心数值逻辑(如生成器产出概率、物品升级链条、体力消耗与产出平衡),设计并制作了第一版临时数据配表(Excel/CSV),便于后续框架开发​3.其他AI辅助工具横向尝试:​◦拓展尝试了除CodeBuddy之外的其他AI编程/全栈辅助工具(如Cursor、Claud等),在网络环境上遇到了一些问题,有些模型时需要外网环境才能使用,比如接入Codex的API后显示网络有问题,明天找程序帮忙解决。​成果​•美术临时资源:生成了一批临时Icon和UI素材,便于后续开发​•临时数值配表 v1.0:确立了基础物品合成树及产出概率表,为下一步原型注入动态数据做好了准备。​item.xlsx心得体会​•AI 辅助开发的广度与深度感知:在今天对 Cursor以及各类美 + +--- + +### 王雨默 (2026-05-20 04:22:08) +链接: https://dianchukeji.feishu.cn/wiki/XRMpwLyT6i55YykYcZScuyRWnyh + +> 日报-王雨默输入“/”快速插入内容2026.5.19-日报-王雨默​用户2965用户29655月20日修改一.工作内容概述​•修复碎片收集界面在真机测试过程中出现的“碎片显示异常”、“动画表现异常”问题。​•确认项目美术概念方向,尝试建立规范,在后续工作流中最大限度保证美术资产的风格一致性,​•Responses API 生图链路验证,UI 生图工作流方案收敛​​二.美术概念方向确定​1.抖音小游戏主流品类与美术风格分析​主玩法品类​代表方向 / 产品​常见美术倾向​核心优势​对项目的参考价值​IAA休闲 / 超休闲​抓大鹅、羊了个羊、拧螺丝、挪车、倒水排序、机关消除类小游戏​明快卡通;图标大而清晰;操作区域突出;道具入口明显;成功、失败、奖励反馈强​用户能快速理解玩法,适合短局体验、广告变现和短视频传播​可以借鉴其短局节奏、提示广告、通关反馈和分享挑战设计,但不能只做成安静的逻辑题界面​二合模拟经营​浪漫餐厅、四季合合、梦幻旅行、家园修复、餐厅经营、百货店经营​温暖治愈;生活化场景;低饱和暖色;角色亲和;UI 圆润;装修、收集、任务反馈较强​长期目标感和留存能力较强,能通过建设、收集 + +--- + +### 卓泽 (2026-05-20 01:28:09) +链接: https://dianchukeji.feishu.cn/wiki/ZdTPwDH8NiSh09kOuHicQvLSnZd + +> 日报-卓泽输入“/”快速插入内容20260519-日报-卓泽​用户4681用户46815月20日修改一.今日工作内容概述​•继续推进新游戏内容接入,围绕武器、敌人、宝箱、美术特效和相关配置做了完整整合。​•同步补充了部分游戏数值相关工作,尝试调整一套提示词让Agent进行数值体系设计,并围绕基础成长、配置映射和数值表现联动做整理与调整。​•继续处理粒子特效与战斗表现相关内容,让命中、爆破、受击、开箱等关键反馈在视觉层面更完整、更统一,也让战斗过程中的反馈层次更清晰。​​二.新游戏内容接入推进​1.武器、敌人、宝箱与特效资源整合​•今天的重点仍然是把新游戏内容从“有资源”推进到“可接入、可配置、可验证”的状态。​•在武器资源方面,继续完善了资源导入、配置映射和表现接入,让武器不只是静态素材,而是能够被系统正确识别和使用。​•在敌人资源方面,补充了敌人测试资产和相关配置,便于后续快速验证敌人表现、战斗交互和阶段流程。​•在宝箱资源方面,补齐了宝箱相关美术资源和开箱特效,使奖励展示和战斗反馈链路更完整。​•在美术特效方面,继续接入战斗中常用的命中特效、爆破特效、耗尽特效等内容,增强整体表现一 + +--- + +### 韦译 (2026-05-19 20:41:01) +链接: https://dianchukeji.feishu.cn/wiki/KGMJwIMWOiMnnVk2wyrc0OaRnkh + +> 日报-韦译输入“/”快速插入内容260519日报-韦译​用户6299用户62995月20日修改1.工作内容概述​1.研读三份报告,调整自己的开发计划​2.把目前的小型闯关制度,改成类《浪漫餐厅》的大型关卡长时间推进机制​3.游戏内ui继续改进:接入订单区域背景图、餐桌、餐盘,实现订单区域的拖拽,但有仍有不少问题​4.目前游戏的性能差,有很多卡顿,需要优化(发现web网页端不卡,只有编辑器卡,经过跟AI讨论,目前以真机的体验为准,编辑器只做参考)​5.开始开发无限订单机制,预计明日完成​2.进度​2.1 研读三份报告,调整自己的开发计划​◦之前的开发计划主要围绕开发本身,没有重点考虑资产沉淀、接入商业化功能相关的部分。三个报告文档指出了需要沉淀的具体资产、商业化功能,明确了往后的开发方向。目前已经完成了W1的绝大部分内容,本周剩余时间将重点开发W2中的内容。​◦以后的日报将持续跟踪三份报告中给出的开发计划。在第五节项目规划中更新每日进展。​2.2 把目前的小型闯关制度,改成类《浪漫餐厅》的大型关卡长时间推进机制​◦承接昨天的机制分析,今天开始开发此机制,并完成开发。​▪具体效果:在主界面 + +--- + +### 刘鹏 (2026-05-19 20:38:21) +链接: https://dianchukeji.feishu.cn/wiki/DTPlwRI46iKAgfkKvozcBHF1n7c + +> 日报-刘鹏输入“/”快速插入内容2026.05.19日报-刘鹏​用户2416用户24165月20日修改一、工作内容概述​1.对二合类微信端头部产品浪漫餐厅、四季物语、四季合合进行了前期体验调研​2.使用IMA完成宝石主题二合类游戏物品链Schema(JSON格式)​3.配置UnityMCP环境,验证程序工具链生成效果​二、前期调研产出​通过多AI数据收集+人工审核数据准确性的方式,收集当前市场的基础数据​(市场基础情况调研数据)​结论:目前二合市场的主要目标用户为女性轻度休闲用户,且多为年轻女性,用户追求治愈的情感感受和短频快的体验反馈。田园/家居是微信小游戏端最大的流量池,占比高达50%。此类主题更贴近“装修”、“装扮”等泛女性向社交需求,符合“泛用户共鸣”原则,第二大的餐饮美食类的表现也比较稳定,恋爱和IP授权是差异化切入点,但市场验证的产品较少,具有较大的用户改造风险,但同样也适合当前做快速市场验证的阶段目标,因此我觉得可以考虑未验证但存在可能性的潜力主题。​(玩法结构基础调研数据)​结论:核心循环结构:核心合成→【订单】→【装修/剧情/剧本】→【获得新生成器/奖励】→【更高阶订 + +--- + +### 徐锐 (2026-05-19 20:12:20) +链接: https://dianchukeji.feishu.cn/wiki/OY6KwrH1Rifryrk80nSc4aRPnig + +> 日报 徐锐输入“/”快速插入内容2026-05-19-日报 徐锐​用户2199用户21995月20日修改1.工作内容概述​1.AI代码平台搭建:暂定使用CodeBuddy(代码生成工具)+Godot(游戏引擎)+deepseek个人模型​a.选择原因1:Codybuddy与微信小程序生态的工具链兼容性相对较好。​b.选择原因2:godot使用的是codebuddy的定制化版本,使用起来相对方便,另外应该也会有一些专门优化。​c.选择原因3:Godot里的核心场景文件.tscn和核心资源文件.tres,本质上是TOML语法的变体实现。TOML有极强的声明式特征,并且对人类和AI都拥有可读性。AI使用时可以不通过MCP,只通过grep文档的形式直接修改.tscn文件,相比其他软件必须使用MCP辅助更加方便。​d.选择原因4:Deepseek是相对性价比最高的模型,所以想试着先使用,如果后续明确出现了十分困难的阻碍会立即进行替换。​e.选择原因5:个人觉得智能度相对不那么高的引擎能够在一定程度上监督项目具有一个清晰的架构,如果是一个架构十分清晰的项目,这套组合也应该可以实现最终成品。​2.二 + +--- + +### 卓泽 (2026-05-19 02:10:37) +链接: https://dianchukeji.feishu.cn/wiki/WiBfwLPy1iBhk5kHfQPccx2un0f + +> 日报-卓泽输入“/”快速插入内容20260518-日报-卓泽​用户4681用户46815月19日修改​一.今日工作内容概述​•尝试引导Agent跑通美术资产从生成到配置的完整工作流程,整体效果不错,说明这类“重复度高、链路长、规则明确”的任务适合引入 Agent 参与​•继续推进游戏开发工作,主要包括:​◦完成 UI 配置器开发,补齐了当前项目 UI 资源配置和组织的一部分编辑能力。​◦修复了一批现有 Bug,提升了当前版本的稳定性。​◦梳理目前项目中 Unity UI 实现与配置对 AI 开发的优劣,为后续继续用 AI 介入 UI 配置、资源整理和批量数据处理提供参考。​二.关于 Agent 执行美术资产配置​1.背景与目标​•AI 程序已经系统性给出交接文档,按正常流程原本需要由人类逐一完成资产生成与配置。​•但这批资产重复度高、批量大、流程固定,适合让 Agent 介入,把重复劳动交给自动化处理。​•本次尝试的目标不是单次追求最大产量,而是先跑通“生成 -> 处理 -> 落盘 -> 导入 -> 配置 -> 验证”的闭环,确认后续能否稳定扩展。​•交接信息中已经覆盖了总述、敌人资产 + +--- + +### 韦译 (2026-05-18 20:58:05) +链接: https://dianchukeji.feishu.cn/wiki/PXVywSG2bisQxskF9i1cQSqGndb + +> 日报-韦译输入“/”快速插入内容2605018日报-韦译​用户6299用户62995月18日修改1.工作内容概述​1.完成类《浪漫餐厅》的解锁格子机制​2.把目前的小型闯关制度,改成类《浪漫餐厅》的大型关卡长时间推进机制(是一个比较大的功能,还在推进中,预计明日完成)​3.游戏内ui继续改进:订单区域背景图、餐桌、餐盘​4.根据实践经验继续沉淀美术工作流:喵吉托平台和gpt image-2各自有各自擅长的场景​5.研究并整理AI原生的配置方案​2.进度​2.1 完成类《浪漫餐厅》的解锁格子机制​◦简单分析可知,《浪漫餐厅》的棋盘格子有以下机制:​一 四种类型的格子:可直接解锁的格子,锁住的格子,无物品的可合成格子,有物品的可合成格子。​二 可直接解锁的格子中的物品,可以直接二合;同时,把临近一格的锁住的格子,变成可直接解锁的格子。之后,这个格子变成有物品的可合成格子。​◦复刻效果​​2.2 把目前的小型闯关制度,改成类《浪漫餐厅》的大型关卡长时间推进机制​◦简单分析可知,该机制的规则大致如下​▪概述:玩家在home场景和game场景可以来回切换,切回game场景时保留原来game场景的 + +--- + +### 刘鹏 (2026-05-18 20:03:00) +链接: https://dianchukeji.feishu.cn/wiki/ZCzDwSm2Mi8cJJkIeHucbbcun54 + +> 日报-刘鹏输入“/”快速插入内容2026.05.18日报-刘鹏​用户2416用户24165月18日修改一、工作内容概述​1.完成入职培训,熟悉工作环境​2.对齐团队方向和目标,明确后续的阶段性任务​3.安装配置Claude、Unity等开发工具​4.学习超休闲游戏关卡设计与 AI 管线文档,明确后续的工作规划​二、超休游戏关卡设计与AI管线文档的学习收获​学习了解了单人策划+AI工具链开发二合超休类的具体的开发标准和实施步骤,明确项目的目标是做出高质量的产品,跑通落地验证流程,对过程中产出的经验、方法论以及资产进行沉淀。做到快速验证,稳定成长。​三、环境配置​对于codes等一些无特殊配置/配置较为简单的工具软件,可以直接借助trae分发安装任务自动完成下载和配置,降低人工精力的损耗。​四、明日计划​对头部二合游戏进行初步筛选,确定目标场景,选择3-4款产品,借助AI深度分析,产出设计计划。​​ + +--- + +### 徐锐 (2026-05-18 18:59:00) +链接: https://dianchukeji.feishu.cn/wiki/KQ98wIYoJiljDFkoqrfcXf5bnme + +> 日报 徐锐输入“/”快速插入内容2026-05-18-日报 徐锐​用户2199用户21995月19日修改1.工作内容概述​a.新人入职培训与电脑环境搭建​b.超休闲游戏制作方向文档学习​c.merge类产品初步调研与思考​2.成果​​merge产品对比快速拆解与分析​3.心得收获​a.AI学习与开发流程:更加细致地了解了超休闲游戏的开发具体流程与现在前沿的AI方案​b.合成产品设计思考:通过对比游玩多款合成类产品对这类产品的设计方向有了大致的认知,有些merge的成功产品个人感觉还是有一些设计缺陷:​i.2.Merge Cooking和Tasty Travels阴影遮挡的设计会造成视觉欺骗,让玩家觉得自己犯了低级错误从而降低乐趣​4.明日计划​思考关卡实现方式与AI生成尝试​​ + +--- + +### 韦译 (2026-05-18 14:05:56) +链接: https://dianchukeji.feishu.cn/wiki/NSL8whlPbi4Bcmkr0xfcnVcLnxc + +> 内容疑难杂症​用户6299用户62995月18日修改​ + +--- + +### 王雨默 (2026-05-16 00:53:59) +链接: https://dianchukeji.feishu.cn/wiki/VQxswUOvaiUx36kPiq6cNBERnLg + +> 日报-王雨默输入“/”快速插入内容2025.5.15-日报-王雨默​用户2965用户29655月16日修改一.工作内容概述​•继续探索 UI 生图工作流,重点补充 Responses API / Image API 相关认知,并测试中转站 Responses API 接入效果;尝试 asset sheet 合批生成策略,验证其对多元素 UI 资源交付效率提升程度。​•修复项目在抖音开发者工具环境下暴露出的拼图海报渲染、飞行动画和广告刷新相关问题。​​​二.UI生图工作流探索​1.Responses API 认知补充​昨日判断的修正​昨日在分析 Codex 与 ClaudeCode 的生图交付质量差异时,曾倾向认为 Codex 之所以能够更好地完成“从效果图中拆分元素”,可能是因为 Codex 内部可以直接调用 Responses API 图像工具链。​今天进一步探索了解后发现,这个判断需要修正。​更准确的理解是:​•OpenAI 图像生成能力可以通过 Image API 或 Responses API 使用;​•Responses API 的图像工具可以在上下文中接收文本和图片输入,并 + +--- + +### 韦译 (2026-05-15 23:57:00) +链接: https://dianchukeji.feishu.cn/wiki/WnGawSdJHixT8NkzanRc2JsFnbg + +> 日报-韦译输入“/”快速插入内容2605015日报-韦译​用户6299用户62995月15日修改1.工作内容概述​1.推进开发进度:今天主要调整局内UI复刻《浪漫餐厅》布局​2.生成并接入局内游戏界面ui的美术资源​3.梳理自己的程序策划工作流​4.遇到并解决了2个严重影响开发速度的问题:codex网络连接问题以及cocos控制台报错问题​2.进度​2.1 调整局内UI复刻《浪漫餐厅》布局​◦通过拆解《浪漫餐厅》布局,绘制2d简易布局图,快速实现了整体布局的复刻。但是还有一些细微的瑕疵需要调整​◦修复了关卡系统的bug问题,之前会因为空值问题,无法重玩关卡也无法进入下一关。​2.2 生成并接入局内游戏界面ui的美术资源​◦用喵吉托的AI美术平台,生成了人物半身立绘,用于在游戏中展示订单所有人。​ + +--- + +### 卓泽 (2026-05-15 23:04:17) +链接: https://dianchukeji.feishu.cn/wiki/QWWCwp79SiwAV2ky2RDcufDCnxe + +> 日报-卓泽输入“/”快速插入内容20260515-日报-卓泽​用户4681用户46815月15日修改2026.5.15 日报​一、 工作内容概述​•今天主要是开发, 重构了战斗落体逻辑, 打通了包含敌人生成、武器战斗、广告激励及存档在内的完整游戏循环,差美术填充即可进入完全可玩阶段。实现50级武器视觉自动循环与粒子特效, 方便后续开始做资产之后填充, 还修正了敌人格在战斗开始时的瞬移和颜色突变问题​​二、 体验调优​按照合了个合的战斗逻辑进行了重构, 每把武器现在从各自的棋盘格位置独立起跳落体,不再成列排队移动,武器在触碰阻挡敌人时立即触发回弹;同时限制镜头仅向下推进,避免了因武器反弹导致的镜头无序弹跳。​视频▼​三、 项目进度评估​•当前进度正常, 进入系统微调, 补充开发, 填充资产的阶段, 预计下周一/二可以有包含完整美术资产填充版本​四、 明天打算做​•生成并且打磨美术资产, 配置并且调整UI布局​​​​ + +--- + +### 卓泽 (2026-05-15 00:11:41) +链接: https://dianchukeji.feishu.cn/wiki/XylZwP9vcirf8bkffnjcbN1onpf + +> 日报-卓泽输入“/”快速插入内容20260514-日报-卓泽​用户4681用户46815月15日修改一、 工作内容概述​•今天主要还是开发完成了战斗结果相关的系统开发以及测试​•完成了相关系统的开发。支持限时广告开启、累积次数永久解锁、以及资源不足时的广告奖励位​•按照新的设计实现了金币、棋盘武器、关卡进度、生成器与修为进度的存档保存​​二、 核心玩法​进展如视频, 实现了战斗相关的数值系统, 金币的获取以及管理的所有逻辑, 修仙相关的逻辑, 武器生成器逻辑与熔炼销毁逻辑并且初步配置了UI资产后续进行比例细调▼​​三、 项目进度评估与后续计划​当前进度还算正常,按计划推进中, 目前正在进行的“战斗+存储+无限循环”核心模块,预计在 5 月 19 日 之前完成全部游戏流程的跑通​​四、本日研究的项目​ClaudeCode的上下文管理系统​学习自​https://github.com/win4r/cc-notebook/blob/main/Claude_Code%E4%B8%8A%E4%B8%8B%E6%96%87%E5%8E%8B%E7%BC%A9%E7%AE%97%E6%B3%95%E + +--- + +### 王雨默 (2026-05-14 23:30:28) +链接: https://dianchukeji.feishu.cn/wiki/QAdawW4l4iaWSIkf0jDcqVxqngb + +> 日报-王雨默输入“/”快速插入内容2026.5.14-日报-王雨默​用户2965用户29655月14日修改一.工作内容概述​•基于昨日进度,继续探索生图工作流优化方向,重点尝试解决从整体 UI 效果图拆分单个素材时,单个素材无法完全还原效果图样式的问题。​•了解抖音开发者平台相关流程,将 Cocos 项目构建后导入抖音开发者工具,并针对抖音环境下暴露出的各种问题进行排查与修复。​​二.生图工作流探索​之前的测试发现,ClaudeCode在后续拆分阶段使用 image2 对单个元素进行重新生成,只能保证风格统一,却无法保证样式还原,初步怀疑是提示词和拆分策略的原因。​因此今天分别使用Codex和ClaudeCode,基于相同提示词、相同参考图,连续执行了三次拆分任务,用于观察两者在稳定性与还原度上的差异。​1.测试结果​对比项​Codex原生环境​ClaudeCode 调用 Image2​多次输出稳定性​稳定​较稳定​风格一致性​稳定​较稳定​与效果图还原度​几乎完全还原效果图​只能做到风格相近​资产细节​保留度更高​容易发生重构​中文文字 / 图标细节​清晰还原​容易变形或重写​同样是 + +--- + +### 韦译 (2026-05-14 21:49:03) +链接: https://dianchukeji.feishu.cn/wiki/OqVjwMswbiMXHukGZZZcc9g3nnc + +> 日报-韦译输入“/”快速插入内容2605014日报-韦译​用户6299用户62995月14日修改1.工作内容概述​1.对Meow Art游戏美术生成平台进行调研和尝试​2.推进二合项目的基础功能的开发​2.对Meow Art游戏美术生成平台进行调研和尝试​Meow Art是喵吉托工作室推出的一款AI游戏美术生成工具,主要功能包括创建2d像素美术资源、2d高清美术资源、游戏音效资源。其中主打的类型是:角色素材和icon资源。并且还具有API拓展能力,后续能够接入自制的ai美术工作流中。​2.1 角色素材​包括静态角色和动态精灵图,有像素风格、高清风格​◦特点:动作流畅,并且细节清晰,人物一致性强。​2.2 icon资源​◦特点:ai味很弱,几乎看不出是ai生成的;并且自带透明背景,不需要自行抠图;细节丰富的同时,风格极其一致。​2.4 尝试​使用高清风格,为当前的二合项目生成了一批icon,效果非常不错。​ + +--- + +### 韦译 (2026-05-14 01:15:59) +链接: https://dianchukeji.feishu.cn/wiki/DSD4wa3wBiXGxqkg87icUiHHnoe + +> 日报 韦译输入“/”快速插入内容2605013日报 韦译​用户6299用户62995月14日修改一、工作内容概述​1.对AI全栈工作流进行梳理,明确重点研究方向​2.项目的前期准备与开发​3.遇到并解决的几个坑:1 claude限额 2 codex网址配错、3 cocos mcp问题​二、AI全栈工作流的梳理​从目前开发实践经验来看,目前AI全栈开发工作流主要分为以下几大方向​一 从策划设计到程序实现的工作流​二 从概念到资产的美术包装工作流​三 针对某个特定内容的工作流​例如:就本项目的二合游戏而言,怎么利用ai生成合理的关卡而不靠传统的模板库或者手工生成,就是一个特别值得研究的方向。​目前在考虑本项目中,应当重点沉淀哪个工作流。​1.如果重点沉淀美术包装工作流,则需要和雨默错开,他正在研究一套高可自定义的工作流。个人认为可以调研第三方的美术工作流拓展视野,例如meow art。​2.如果重点沉淀从策划设计到程序实现的工作流,则优先梳理当前自身程序策划的工作流,总结优缺点。​3.如果重点沉淀针对某个特定内容的工作流,个人认为是比较具有挑战但非常有价值的。但沉淀这种类型的工作流需要在功 + +--- + +### 王雨默 (2026-05-14 00:05:02) +链接: https://dianchukeji.feishu.cn/wiki/VFeCwF4VsizD4Bkri2Rc62junbf + +> 日报-王雨默输入“/”快速插入内容2026.5.13-日报-王雨默​用户2965用户29655月14日修改一.工作内容概述​•完成抽奖系统剩余部分逻辑,修复bug​•测试生图Skill进阶模式执行链路,并对其进行优化​二.生图Skill进阶模式测试优化​1.测试情况​最开始几次测试时,发现流程并没有完全按照预期运行,主要问题包括:​1.一些已经约定好的流程步骤没有被严格执行;​2.provider 的相关配置没有被持久化保存,导致多次调用之间配置不稳定;​3.某些本应向用户确认的步骤被跳过;​4.部分阶段虽然状态显示已完成,但实际中间产物并不稳定;​5.生成、拆分、后处理、交付之间的衔接还不够清晰。​经过多轮修复后,进阶模式已经能够按照预期流程运行,并最终完成图片资产交付。但在当前默认链路下,交付质量、资产风格一致性以及对参考图的还原度仍然不够稳定。​也就是说,进阶模式现在已经具备基本交付能力,但还需要继续优化生成链路的可控性和稳定性。​前期资产清单确认​50%生成报告,尺寸有bug,后面修复了​50%效果图​交付图,整体风格符合概念图,但是样式没有按照效果图进行还原​2.质量问题与初 + +--- + +### 卓泽 (2026-05-13 22:15:01) +链接: https://dianchukeji.feishu.cn/wiki/GfgYwRD7Yiyac0kVWOtc9WFjn2c](https://dianchukeji.feishu.cn/wiki/GfgYwRD7Yiyac0kVWOtc9WFjn2c) + +> Access DeniedX-TT-System-Error: 3Oncall ID: 783 + +--- + +### 王雨默 (2026-05-13 02:14:15) +链接: https://dianchukeji.feishu.cn/wiki/U32FwRkZPiYu9vkEtXPcRNVVnSe + +> 日报-王雨默输入“/”快速插入内容2026.5.12-日报-王雨默​用户2965用户29655月13日修改一.工作内容概述​•抽奖系统核心逻辑实现,包括抽奖入口、奖励配置读取、抽奖结果生成与基础状态流转。​•优化生图工作流,引入第三方后处理抠图 provider,调整透明背景处理策略。​​二.生图工作流优化​1.引入第三方后处理抠图服务​之前Skill的后处理主要依赖本地脚本,比如纯色背景抠图、边缘清理、去杂边、透明通道修复等。这套方式对简单 UI 元素基本可用,但在复杂素材上,本地处理的输出质量上限较低。​对韦译分享的网站https://www.koukoutu.com/进行了测试,发现其能够承担复杂图片的抠图工作、输出边缘清晰的透明背景png图片,且提供开发者API。现尝试将其引入生图工作流中。​2.新工作流优化​暂时去除了之前“纯色背景生成 + 本地脚本抠图”的流程,而是优先使用原生透明图;如果没有可靠透明背景,则使用第三方抠图服务。​这次调整的核心意义在于:​•去掉了对纯色背景的依赖;​•去掉了本地脚本抠图带来的不稳定因素;​•提高复杂素材透明背景的质量上限;​•减少本地参数调 + +--- + +### 韦译 (2026-05-12 22:48:57) +链接: https://dianchukeji.feishu.cn/wiki/IGr9wUHPUi6dMwkE1s6cVKPfnGe + +> 内容在Claude Code中使用AWS的API​用户6299用户62995月13日修改1 下载并安装AWS CLI​https://awscli.amazonaws.com/AWSCLIV2.msi​​2 配置aws configure​在命令行中输入:aws configure​按提示依次输入 AK、SK、区域(us-east-1)、输出格式(回车跳过)。​如下:​•AWS Access Key ID:你的 AK​•AWS Secret Access Key:你的 SK​•Default region name:us-east-1​•Default output format:直接回车​🌰这里的ak和sk,指的是AWS那边配发的Access Key和Secret Access Key,需要向IT同学申请​3 Claude Code 配置​3.1 打开claude的配置文件:​3.2 在配置文件中写入:以下内容​{​"env": {​"CLAUDE_CODE_USE_BEDROCK": "1",​"AWS_REGION": "us-east-1",​"ANTHROPIC_MODEL" + +--- + +### 卓泽 (2026-05-12 22:48:29) +链接: https://dianchukeji.feishu.cn/wiki/ZKeNw6V9ViwCH3kyAM9cOYSpntf + +> 日报-卓泽输入“/”快速插入内容20260512-日报-卓泽​用户4681用户46815月13日修改2026.5.12 日报​一、工作内容概述​•在昨天跑通基础游戏循环的基础上,继续推进二合增量游戏从可玩到完整过渡,重点完善存档、测试控制台、Prefab 接入、金币生成逻辑和 UI/资产替换流程。​•封装了一个可供 AI 稳定调用的图像抠图工具,支持输入图像并输出透明底素材,为后续 AI 生成美术资产后的自动化处理做准备。​•配通 Amazon Bedrock Claude 4.6 在 OpenCode 中的调用方式,并初步配置试用 Codex/goal,继续补齐 AI 辅助开发工具链。​•整理并写入 SO 配置与开局接入说明文档,用于后续规范项目配置、UI 皮肤、合成物素材和大等级链条的接入方式。​二、工具链与资产生产​2.1 AI 抠图工具封装​今天封装了一个输入图像、输出透明底图片的工具,基于https://sync.koukoutu.com/v1/createAPI 实现。这个工具后续可以作为 AI 美术生产链路的一部分:当 AI 生成角色、建筑、道具或 UI 元素后,可以自动 + +--- + +### 韦译 (2026-05-12 22:47:25) +链接: https://dianchukeji.feishu.cn/wiki/NkY6wVzfliQAyykiWsEcaN9cnue + +> 日报输入“/”快速插入内容2605012日报​用户6299用户62995月12日修改一、工作内容概述​1.入职培训、熟悉工作环境​2.安装开发环境和ai工具​3.跑通AWS的API接入Claude Code的流程​二、在Claude Code中使用AWS的API​​在使用api接入claude code这种agent工具的过程中,发现AWS的api不同于以往的url加key的接入方式,采用比较特殊的ak➕sk的接入方式,在熟悉这个接入方式时花了不少时间​遇到的主要问题有2个​一 不熟悉AWS的ak➕sk的接入方式​二 配置代理环境时,不熟悉具体操作:即使用ak➕sk的方式配置好了,也仍然大概率会卡在Claude code的配置代理问题(claude code需要单独配置代理)。​​在嘉辉老师的帮助下,得出临时性的解决方案如下​​在Claude Code中使用AWS的API​​三、收获与反思​1.个人对Claude code的代理配置工作有进一步的了解​2.计划编写帮助文档,帮助后入职的同学快速上手​计划:帮助文档分以下3大板块​•开发环境配置​◦主要阐述node、代理配置、命令行等开发 + +--- + +### 王雨默 (2026-05-12 00:22:24) +链接: https://dianchukeji.feishu.cn/wiki/F8jiwgDmkiyzLMk5KYecuOjinAg + +> 日报-王雨默输入“/”快速插入内容2026.5.11-日报-王雨默​用户2965用户29655月12日修改一.工作内容概述​•完成皮肤系统逻辑实现​•继续探索优化Codex生图工作流​二.Codex生图工作流优化​1.GPT Image-2 即时模式​今日探索发现:GPT Image 2 的即时模式(Instant 模式)可以直接生成带真实透明背景的 PNG 图片。​这个发现说明,之前 Skill 中默认采用的“纯色背景 + 后处理抠图”流程,并不是所有情况下都必须执行。如果生成阶段本身就能输出真实透明背景,那么部分后处理抠图步骤就有机会被省略或降级。因此,今天主要围绕以下问题继续对 Skill 进行优化:​•不同生图模式在流程中应该如何分工;​•是否应优先使用真实透明背景,而不是默认纯色背景;​•是否可以接入第三方生图服务;​•是否可以通过资产图集提高批量生成效率;​•这套 Skill 是否具备迁移到其他 AI Agent 的可能。​​2.即时模式和思考模式​测试中发现,GPT Image 2 的不同生成模式有明显差异:​即时模式​即时模式的优势是:​•可以直接生成真实透明背景 PN + +--- + +### 卓泽 (2026-05-11 20:06:34) +链接: https://dianchukeji.feishu.cn/wiki/YmolwbdlOikKWMkGgQmcTflMnQe + +> 日报-卓泽输入“/”快速插入内容20260511-日报-卓泽​用户4681用户46815月12日修改一、工作内容概述​•基于前期架构文档正式启动二合增量游戏的编码实现,按照完整架构思路搭建了包含完整核心系统边界的 MVP 原型​•创建对应测试 Scene 进行运行验证,完成棋盘、合成、资源、任务、UI 与测试工具等基础链路的调试​•复盘此前 API Key 异常用量问题,并且了解了背后的隐式思维链模型的技术基础​二、重点工作推进​2.1 完整架构 MVP 原型编码​此前已经完成二合增量游戏的整体系统拆分与核心流程设计,今天开始将这些结构落实到工程中, 从架构设计文档进入实际开发,目标不是先写一个孤立的小 Demo,而是在 MVP 阶段尽早按完整架构搭出可运行的基础骨架,方便后续逐步替换表现层、补充素材和扩展系统。​本次已按照架构创建并接入了核心游戏框架代码,覆盖棋盘、合成、资源、任务、UI、存档和运行时测试辅助等模块。当前测试 Scene 已能在完整架构下运行,支持基础棋盘显示、物品生成、拖拽、合成、资源变化和任务反馈等流程,为后续继续迭代玩法、表现和数据配置提供了可验证基础。​开发过 + +--- + +### 卓泽 (2026-05-10 11:34:30) +链接: https://dianchukeji.feishu.cn/wiki/RdWtwxGwPi4DRzkhpOEc6S84nsf + +> 日报-卓泽输入“/”快速插入内容260509-日报-卓泽​用户4681用户46815月11日修改2026.5.9 日报​一、工作内容概述​•调研 AI Skill 生成器工具(dot-skill 与 nuwa.skill),完成对标分析。​•基于 dot-skill 部署 colleague-game-tdd-writer Skill,用于将游戏核心设计要素、策划案与目标引擎转化为结构化系统架构与技术策划文档。​•使用该 Skill 完成二合增量游戏的完整架构设计文档(v0.3),输出包含 Mermaid 流程图、配置表定义、MVP 范围划定及边界条件覆盖。​二、重点工作推进​2.1 背景与目标​下一阶段将启动一款二合(Merge-2)增量循环类休闲游戏的 AI 全栈开发,引擎为 Unity 6(UI Toolkit)。在正式编码前,需要将零散的设计思路转化为系统化的技术策划文档与架构蓝图,以降低开发过程中的方向偏移和返工。本次尝试用定制化 AI Skill 自动化"设计概要 → 架构文档"这一环节。​2.2 今日完成内容​1.Skill 生成器调研​对比了 dot-skill 与 n + +--- + +### 王雨默 (2026-05-10 03:02:35) +链接: https://dianchukeji.feishu.cn/wiki/EpZZw1rT9iBZDFkrwo2cgImpngb + +> 日报-王雨默输入“/”快速插入内容2026.5.9-日报-王雨默​用户2965用户29655月10日修改一.工作内容概述​•碎片收集系统功能收尾,bug修复​•参照agent-sprite-forge项目,仿写 Codex 生图 Skill​​二.参考项目学习分析​参考了agent-sprite-forge项目的设计思路。该项目的核心并不是简单提供一组 sprite prompt 模板,而是提供了一套面向 Agent 的 2D 游戏资产生产流程。​参考项目:https://github.com/0x0funky/agent-sprite-forge​它的基本工作方式是:​代码块​Plain Text用户提出 sprite / map / prop 等资产需求​↓​Agent 理解需求,判断资产类型、动作、帧数、布局和风格​↓​Agent 调用自身可用的 image generation 能力生成 raw asset​↓​Python 本地脚本进行后处理​↓​输出可用于游戏工程的 PNG / GIF / metadata​其中最值得参考的是它对职责的拆分:​•Agent 负责创意判断和流 + +--- + +### 卓泽 (2026-05-09 06:29:32) +链接: https://dianchukeji.feishu.cn/wiki/CHZiwHehNizCJKkhZqccilaknMd + +> 日报-卓泽输入“/”快速插入内容260508-日报-卓泽​用户4681用户46815月11日修改一.今日工作内容概述:​•对抖小/微小排行榜头部休闲品类(重点针对二合及AI适配度)的发散调研结束, 进入二合核心玩法的开发阶段​•游戏具体系统拆解与架构与设计(部分完成)​•Unity, Git, Opencode的开发环境配置​二.品类调研相关​微小与抖小热门榜前列的二合游戏​•​排行榜及其具体休闲品类排行榜游戏类型分析​抖小/微小休闲品类调研总结​1.二合品类现状:​◦目前排行榜头部的二合(如《浪漫餐厅》、《四季合合》)基本被“二合+剧情+线性装修”的框架垄断,微小端同理。《Travel town》虽然混变,但大循环基本相同,二合占比稍多。​◦发现的高优适配方向:抖小前列的《合了个合》。这类IAA属性强,游戏复杂度适合作为第一步入手点,且玩法驱动模型更适合AI后续介入开发。​画板2.其他高适配度/AI提效潜力品类 储备记录:​◦箭头消除/车辆消除(如《超级消消》、《套住那只羊》):双端热门,其资产开发、关卡设计极具扩展性,非常适合AI高度介入,复杂度适中。​◦一笔画/画之谜:抖小热门前 + +--- + +### 王雨默 (2026-05-09 01:33:11) +链接: https://dianchukeji.feishu.cn/wiki/NzSOwDHlgiPCx9klcKWcxzawnhe + +> 日报-王雨默输入“/”快速插入内容2026.5.8-日报-王雨默​用户2965用户29655月9日修改一.工作内容概述​•持续推进碎片收集系统进度​•尝试使用AI制作图片处理工具,解决之前遇到的“边缘问题”​二.图片处理工具​问题背景​在之前的尝试中,AI生成的单个按钮、图标或面板,视觉上看起来可用,但边缘像素通常不适合直接作为游戏资源使用,体现在如下方面:​•背景不是真实透明背景,而是被绘制上去的真实像素。​•使用AI进行抠图无法解决边缘问题,产出的图片边缘存在大量瑕疵,完全无法使用​尝试思路​尝试使用AI编写工具来进行资源的处理,思路如下:​1.临时背景识别色​使用特定颜色(如洋红色#FF00FF) 作为临时背景识别色工具通过这个颜色判断背景区域。但不能简单地把所有接近#FF00FF的像素都删除,因为素材内部也可能有粉色、紫色高光或装饰。因此需要通过“外部连通区域”来识别真正背景。​2.保留内部质感,清理外部污染​处理原则是:​也就是说,目标不是把素材变成纯扁平图形,而是把它处理成:主体仍然有质感,但外部轮廓干净、透明、无紫边。​3.高像素输入后再缩放导出​如果输入图是高像素版本, + +--- + +### 王雨默 (2026-05-08 01:50:47) +链接: https://dianchukeji.feishu.cn/wiki/KRxGwTZ0miRVMMk0fjPcIVv7nge + +> 日报-王雨默输入“/”快速插入内容2026.5.7-日报-王雨默​用户2965用户29655月8日修改一.工作内容概述​•碎片收集系统数据框架、UI初步搭建​•实现碎片拼图效果绘制逻辑​•基于昨日进度,继续尝试GPT-Image2生图​​二.碎片拼图效果实现​预期效果​1.碎片拼图视觉效果​◦碎片海报应当呈现接近真实拼图的效果,海报外边缘保持平直,内部碎片边缘呈现凹凸互补,而不是简单的矩形切图。​◦每张海报会根据配置被切分成不同数量的拼图碎片,例如 4x6、5x6、9x15 等。​◦不同切分数量下,碎片形状可以不同,但海报内容必须保持连续。同一张图片在同一归一化位置上的采样内容应保持一致,不会因为碎片数量变化导致整张图案整体偏移或每片独立拉伸。​​2.轮廓线表现​◦轮廓线只用于表达“未收集区域”的拼图形状,不干扰已经收集到的海报内容。​◦已填充碎片不显示轮廓线,避免完整海报画面被线条切碎。​◦玩家已经收集到的区域应当更像真实图片,而不是一堆被描边的小块。未填充碎片继续显示拼图轮廓,用来提示剩余空位的位置和形状。​◦轮廓线应当粗细稳定、透明度一致。相邻未填充碎片之间的共享边只绘制一次,避 + +--- + +### 卓泽 (2026-05-07 22:56:48) +链接: https://dianchukeji.feishu.cn/wiki/NjkVwE5b2iG9wbksmy5ciSqDnDp + +> 日报-卓泽输入“/”快速插入内容260507-日报-卓泽​用户4681用户46815月9日修改一.今日工作内容​•了解二合品类各类型不同的游戏, 部分调研了其他抖小排行榜前列品类的游戏​•初步体验浪漫餐厅, 初步拆解整体循环与游戏逻辑​二. 工作内容概述​​1. 《浪漫餐厅》系统循环初步拆解​《浪漫餐厅》属于典型的二合+模拟经营的复合品类。其系统融合了合成类的空间管理+经营类的长养成​画板​•循环上: 将长线的餐厅建设目标,切割为无数个即时可见的合成配方。将长线积累的模板为可视化的微小正反馈, 在合成大件产生快感的同时, 把抓马而富有悬念的剧情与线性装修作为奖励, 平滑丰富了玩家的体验曲线走出,掩盖了一般长线积累的枯燥感。通过生成器的冷却时间与体力恢复机制,控制玩家的单次游戏时长与内容消耗速度,培养碎片化登录习惯。​•背包上:棋盘的网格数量是游戏内的隐性资源约束。随着高级物品的滞留、不同生成器产出路线的交叉,空间压缩驱动玩家进行资源取舍,或通过内购(购买临时背包、加速冷却道具)来消除"临门一脚完成合成, 却功败垂成"的损失干。​关于二合类后续计划:​•作为IAP游戏, 许多相关资料提到 + +--- + +### 王雨默 (2026-05-07 01:07:15) +链接: https://dianchukeji.feishu.cn/wiki/FFY7wfiFaig3pMkg9H7cFobFn7g + +> 日报-王雨默输入“/”快速插入内容2026.5.6-日报-王雨默​用户2965用户29655月7日修改一.今日工作内容概述​•初步了解抖音平台云服务相关内容,规划后续开发内容​•完善账号数据框架相关内容,并为后续云服务接入做准备​•GPT Image-2使用尝试​​二.账号数据相关​游戏核心数据层重构完毕​•完成了“碎片收集”、“生存模式”和“皮肤系统”三大数据模块的独立拆分。​•将所有新模块统一集成到玩家主数据中,彻底清理了旧版的零散字段和废弃代码,使数据结构更加清晰。​​抖音云存档方案​•查询了解抖音云官方文档,计划以“云托管”方式接入云存档,同步输出相关设计文档和后续开发计划的修改。​•搭建了全新的本地存档管理机制,在不改变原有游戏功能的前提下,为后续连接云端搭好了框架。​​三.GPT Image-2 使用尝试​尝试目标​•通过 AI 生成与后处理方式,获得可直接用于游戏工程的,可直接交付的UI分层资源。​​尝试记录​直接生成并拆分分层 PSD 文件​•尝试内容​◦基于完整主界面效果图,尝试将画面中的 UI 元素按功能模块拆分,并输出为 Photoshop 可打开的分层 PSD + +--- + +### 卓泽 (2026-05-06 21:58:20) +链接: https://my.feishu.cn/wiki/LSY7we2ceiJ5s5kOJwoclB77nXc + +> 日报260506输入“/”快速插入内容日报260506​用户2349用户23495月7日修改本日主要做了的事情:​今天主要做了两块事情:​1.入职准备,包括与新员工相关的入职培训通用办公环境的配置,软件安装等前期准备​2.尝试确定接下来要做的项目的主题​a.尝试进行项目组的目标对齐​b.休闲类/AI原生题材游戏的调研​c.开始撰写项目立项案初稿​本日工作总结:​今天主要还是适应环境,还有一些疑惑希望能够在后续出的初稿得到解答​ + +--- + +### 王雨默 (2026-05-01 02:38:52) +链接: https://dianchukeji.feishu.cn/wiki/Gh8cw3QnJiplq1k2lmFcajidnHl + +> 日报-王雨默输入“/”快速插入内容2026.4.30-日报-王雨默​用户2965用户29655月1日修改一.工作内容概述​•开始账号数据框架搭建,完善体力系统相关功能​•工作流优化探索,尝试引入Codex审查步骤;结合Obsidian进行相关文档、开发日志整理。​​​二.工作流优化探索相关​尝试使用 Codex 插件进行功能审查​1.背景与痛点​目前中大型功能由 Agent Team 协作完成后直接提交,缺少独立的外部审查环节,即使原流程中已经有审查验证步骤,还是会有BUG遗漏。​​2.今日实践​在ClaudeCode里安装了Codex插件,在体力系统代码完成后,执行了/codex:review。Codex 作为"外部 reviewer",从第三方视角审查了工作树 diff,审查范围覆盖全部变更文件。​​3.效果评估​•效果&成本收益:审查耗时约 3-5 分钟,成功发现4个有效问题。​•后续考虑:将这一步骤作为复杂功能(涉及多文件改动)的固定收尾步骤​​4.待优化点​•触发方式:目前 Codex review 是手动触发(/codex:review),后续可考虑写入rules,在Age + +--- + +## 三、dc战略问题研究院文档详情 + +共 46 篇文档 + +### 胡辉俊 (2026-05-19 01:11:08) +链接: https://fcnlycv6dd0w.feishu.cn/docx/ErwhdZhR3oJjoNxGB85cQBicnge + +> + +--- + +### 夏莲 (2026-05-19 01:10:55) +链接: https://fcnlycv6dd0w.feishu.cn/docx/KlGYddZoOo2UD9xIEVgcNqQ3n5c + +> 日报-夏莲输入“/”快速插入内容2026.05.18-日报-夏莲​用户4109用户41095月19日修改一、工作内容概述​1.完成三份汇报文档:文字版报告、PPT报告、整改报告​2.了解学术研究Agent​​二、了解学术研究 Agent​近一年,学术 AI Agent 研究从单点辅助工具转向了“科研流程型 Agent”。主要覆盖文献检索、假设生成、代码实验、数据分析、图表生成、论文写作和自我评估等环节。​​(一)科研协作者类 Agent​代表:SciSciGPT、Google AI co-scientist​强调在人类研究者主导下,AI 作为科研助手或协作者参与具体环节。主要帮助研究者完成文献理解、问题拆解、数据分析、结果解释和研究方案生成。​【SciSciGPT】​论文:SciSciGPT: advancing human–AI collaboration in the science of science​发表期刊 | 年份:Nature Computational Science(2025 年 12 月)​解决的问题:论文认为,现在科研越来越依赖大规模数据和复杂计算方法,但这会带 + +--- + +### 莫润麟 (2026-05-19 01:10:51) +链接: https://fcnlycv6dd0w.feishu.cn/wiki/YEAcwAuHkiGwngk4z48cLBzWnth + +> 日报-莫润麟输入“/”快速插入内容2026.5.18-日报-莫润麟​用户5855用户58555月18日修改今日内容​①整理导师反馈整改内容汇总​②交叉检验开题报告、PPT 与整改汇总​③AI辅助工具搭建:基于Gemini Gem的DBA开题报告智能评审​一、整理导师反馈整改内容汇总​重点将各项反馈拆解为:​•教授提出了什么问题;​•如何理解该问题;​•对应在 PPT 或文字版开题报告中做了哪些调整;​本次整理重点覆盖:​•七机制主次分层与理论展开;​•公平性、激励性等机制边界澄清;​•互动性、流动性动态分析边界补充;​•两团体模型向多团体场景的承接说明;​•变量构建、机器学习识别与治理输出路径补强。​二、交叉检验开题报告、PPT 与整改汇总​对当前最新版开题报告正文、答辩 PPT 和整改说明材料进行了交叉核对,重点检查三类问题:​1. 教授建议是否真正落实到材料中​•核实七机制展开、游戏案例补充、文献空白、理论与实证分开、治理输出等关键修改,均已在 PPT 中体现。​2. 整体质量审核与阶段性评分​•从DBA 开题标准和三位教授反馈要求两个维度,对当前材料的完整度、逻辑性与说服力进行复 + +--- + +### 陈楚真 (2026-05-18 23:55:05) +链接: https://dianchukeji.feishu.cn/docx/SFrYdULAvo9Z1oxVUHvcReOcncW + +> + +--- + +### 张家振 (2026-05-17 01:36:07) +链接: https://ocnmca6f1o0p.feishu.cn/wiki/FFlCweEYqiBlPPkSUzHc1S6bnIc + +> Error: HTTPSConnectionPool(host='ocnmca6f1o0p.feishu.cn', port=443): Max retries exceeded with url: /wiki/FFlCweEYqiBlPPkSUzHc1S6bnIc (Caused by SSLError(SSLEOFError(8, 'EOF occurred in violation of protocol (_ssl.c:997)'))) + +--- + +### 夏莲 (2026-05-17 01:36:02) +链接: https://fcnlycv6dd0w.feishu.cn/docx/TXNAdSOe2oLdrLxYswZckoR9nUd + +> 日报输入“/”快速插入内容2026.05.16-深圳研究部日报​用户2119用户2119用户5855用户58555月17日修改参加《老李的游戏课》36期培训课​深圳研究部参与人员:夏莲、莫润麟、胡辉俊、张家振​本期主题:关于“率土LIKE-SLG产品系列”的分析探讨​​一. 《"降肝减氪"引发的系统重构与生态演化》​分享人:广州战略研究部 陈楚真​(一)重点提炼​1.市场破局:降肝减氪的底层框架重构​•率土类SLG的核心痛点是三高门槛:​◦高时间成本(需手动铺路、定闹钟打城)​◦高氪金成本(以《三战》"孙10万"锁卡机制为典型)​◦高社交成本(强同步性考核),导致品类长期小众​•三谋的破局路径是将劳动密集型模式重构为策略与社交主导的自立运行模式:​◦减氪:取消锁卡、降低保底、缩短养成周期、压缩付费差距,平民玩家拥有完整参与链路​◦降肝:自动铺路、预约打城、结义托管,将机械性重复操作交给系统,玩家专注决策与社交​2.副作用:长草期结构性问题​•降肝减氪使内容消耗速度指数级加快​◦三谋赛季有效时间从约50天压缩至14天左右,较三战/率土加速3-4倍,玩家有60%时间处于长草期​•赛季无法无 + +--- + +### 夏莲 (2026-05-17 01:35:58) +链接: https://fcnlycv6dd0w.feishu.cn/docx/V9ejdL4QBo6XpZxWxPDcVNRMnNh + +> 日报-深圳研究部日报输入“/”快速插入内容2026.05.16-日报-深圳研究部日报​用户4109用户4109用户5855用户58555月17日修改一、工作内容概述​1.针对调整问题进行整改​​二、问题整改​(一)“多人”概念需要前置交代​提出问题:​目前对“多人”的解释不够清晰。需要在论述前段讲清楚多人的具体含义,以及围绕这一主题要解决什么核心问题,并通过文献综述支撑关键问题的提出。​调整说明:已新增并前置“多人社交竞争”的概念界定内容。​已调整内容:​1.新增“概念界定:多人社交竞争游戏​所称“多人游戏”并非简单指人数,而是个体嵌入团体、团体进入赛局、赛局置于竞赛中的多层嵌套竞争结构,因此平台治理的重点不再只是单局胜负,而是持续投入、组织协作与生态稳定。​2.补充“单人 / 简单竞技”与“多人社交竞争”的对比​从核心驱动要素、交互特征、平台角色和管理重点四个方面说明区别。​3.突出本文研究对象的多层嵌套结构​通过结构图展示个体、团体、赛局、竞赛之间的层级关系,说明持续投入不是单一用户行为,而是多层结构共同作用的结果。​75%​25%(二)背景部分关键理论锚点需要更突出​提出问题:​ + +--- + +### 胡辉俊 (2026-05-16 02:02:49) +链接: https://fcnlycv6dd0w.feishu.cn/docx/GcKkd0H5EoQY9KxKiSVcZ05VnVc + +> + +--- + +### 夏莲 (2026-05-16 02:02:48) +链接: https://fcnlycv6dd0w.feishu.cn/docx/JfNIdEbJ3o9QLOxlaHzcs7X7nkh + +> + +--- + +### 莫润麟 (2026-05-16 02:02:25) +链接: https://fcnlycv6dd0w.feishu.cn/wiki/FdI2woTLai6GPDkpPqrcFXYZnGh + +> 日报-莫润麟输入“/”快速插入内容2026.5.15-日报-莫润麟​用户5855用户58555月16日修改今日内容​①优化调整开题报告内容​②制作PPT​一、优化调整内容​(一)问题三:互动性与流动性的长期动态分析路径需要进一步说明​提出问题:​互动性机制与流动性机制本质上都属于长期动态机制,但当前博弈论推导更多是在刻画机制成立的理论条件与均衡逻辑,容易被理解为用相对静态的模型直接替代长期动态效应本身的识别。​具体而言:​•互动性关注的是团体之间在重复互动中,是否会逐渐形成默契避战、低竞争合作甚至类共谋关系​•流动性关注的是成员迁移、联盟扩张与组织结构固化,是否会在跨期演化中放大强者集聚与结构垄断风险​因此,需要进一步明确:理论推导主要用于说明动态机制何以形成,而互动性与流动性的真实长期影响,仍需结合跨期跟踪、动态数据或规则变化观察进一步分析。​调整说明:​围绕这一建议,已从理论边界说明与后续动态识别路径补充两个方面,对互动性和流动性机制完成优化。​1. 已补充互动性机制的动态分析边界​对应位置:互动性机制——"理论推导"结尾​在互动性理论推导结尾新增说明,明确重复博弈模型主要用于刻画 + +--- + +### 张家振 (2026-05-16 01:51:05) +链接: https://ocnmca6f1o0p.feishu.cn/wiki/MKv7w5MX5iW54ykkM7Vcfu6YnTg + +> 日报-张家振输入“/”快速插入内容2026.5.15-日报-张家振​用户9559用户95595月15日修改工作内容概述​1、学习并实践制作知识库​😄昨日旁听了千山项目组同事关于知识库的分享,收获颇丰。计划借助 Cursor 工具动手开发一款知识库应用,在实践中理解知识库的构建与应用流程。​一、RAG 系统简述​RAG 在知识库中的作用是:将大语言模型与外部知识检索相结合,使知识库从被动存储升级为能够主动理解问题、实时召回相关信息并生成有据可依的精准答案的智能系统。​RAG(Retrieval-Augmented Generation,检索增强生成)是一种让大模型在回答问题前先从外部知识库检索相关信息的架构。其核心流程为:用户提问 → 从知识库检索相关内容 → 将问题和检索结果拼接成 Prompt → 大模型生成答案。​RAG 的核心价值在于解决大模型的两个局限:知识截止日期问题和幻觉问题。通过外挂知识库,模型无需重新训练就能访问最新或私有的知识,且回答有据可查。​二、RAG 系统组成​1.数据摄取层:支持多种格式文档的解析和加载(PDF、Markdown、网页等)。​2.文本切片:将长 + +--- + +### 黄静雯 (2026-05-16 01:44:16) +链接: https://dianchukeji.feishu.cn/docx/M8TId6mhhooxZJxHVc5cAwwXnJh + +> 日报-黄静雯输入“/”快速插入内容2026年5月15日工作日报-黄静雯​用户3579用户35795月16日修改一、工作内容概述​1.参加GGS2026全球游戏峰会​​二、GGS2026全球游戏峰会收获与思考​今天参加GGS2026全球游戏峰会(AI研发&中台专场),涵盖了游戏公司在AI爆发时代下的战略选择、从立项、研发、运营、数据分析迭代等各个方面深度应用AI的实践分享,同时也反映出AI时代下对组织文化、架构、工作流、人才提出了新的要求​(一)总体判断:AI正在改变游戏公司的组织竞争方式​本次几场分享共同指向一个趋势:​AI对游戏公司的影响,不只是个人工具提效,而是在重构游戏公司的产品孵化、研发协作、运营迭代、数据决策和组织知识沉淀方式,头部和腰部游戏公司已经进入重构组织生产系统的阶段​游戏公司的竞争正在从“单个项目组能力”扩展至:​•是否有高频创意验证机制​•是否有AI辅助研发工作流​•是否有统一数据与业务语言​•是否有运营/数据/研发高度协同能力​•是否能把项目经验沉淀成AI可调用资产​•是否能让组织持续学习,而不是每次从零开始​​(二)买量驱动公司更容易吃到AI创意验证红利​冰川 + +--- + +### 陈楚真 (2026-05-16 01:42:02) +链接: https://dianchukeji.feishu.cn/docx/SPnWddkXkoY8GaxIUyocufXBngh + +> + +--- + +### 黄静雯 (2026-05-15 09:02:29) +链接: https://dianchukeji.feishu.cn/docx/SOaBdskVhoSXo0x6gvbcLnKHntb + +> 日报-黄静雯输入“/”快速插入内容2026年5月14日工作日报-黄静雯​用户3579用户35795月15日修改一、工作内容概述​1.《三国:谋定天下》、《三国:天下归心》、《三国:冰河时代》、《我的花园世界》体验​2.面试​3.研究组AI研究工作流与产品认知资产库搭建推进​4.创新组全栈 AI 开发方向思考及工作流搭建​​二、研究组AI研究工作流与产品认知资产库搭建推进​原定开发计划包括:​1.三谋三张 draft 卡正式入库 review(已完成)​2.固化 MECH / REPORT / ORG 同源拆分规则(未开始)​3.中规模增量同步验证(未开始)​4.分类候选产物可读化(未开始)​5.target 写回知识库的触发条件梳理(未开始)​(一)今日迭代内容​1.完成《三国:谋定天下》演武大会三张知识卡正式入库​•对三张卡进行了正式入库前 review,并完成正式入库状态切换​•在 review 三张卡的过程中,进一步明确了同一研究资料拆分为多类知识卡时的边界:​◦MECH 卡:回答“机制如何成立”​▪重点沉淀规则结构、机制模型、设计逻辑和可迁移机制​◦REPORT 卡:回答“机制 + +--- + +### 胡辉俊 (2026-05-15 01:46:08) +链接: https://fcnlycv6dd0w.feishu.cn/docx/BbYMdLdBzoVunRxj51ZcP7gxnFd + +> + +--- + +### 莫润麟 (2026-05-15 01:45:54) +链接: https://fcnlycv6dd0w.feishu.cn/wiki/LxmkwF7MRiUJInk3V6Mcn5Xanfu + +> 日报-莫润麟输入“/”快速插入内容2026.5.14-日报-莫润麟​用户5855用户58555月15日修改今日内容​①根据新一轮优化建议进行调整​②参加AI分享会​一、优化调整内容​(一)问题一:公平性与激励性机制边界需要进一步厘清​提出问题:​在七机制框架中对公平性与激励性分别进行了理论建构,但二者在表达和指标选择上存在一定的相近性。​具体而言:​•公平性机制主要通过赛局内团体能力差异、离散程度等指标进行刻画;​•激励性机制中使用奖励分布基尼系数G表征奖励结构集中程度,也带有“差异分布”的含义。​因此,需要进一步讲清:公平性与激励性究竟分别解释什么问题,二者是否存在概念或指标层面的重叠。​🔎调整说明:​当前已从机制界定、边界说明和指标解释三个层面完成优化,进一步明确:公平性关注竞争结构,激励性关注奖励回报结构。​1.已优化激励性机制的界定表述​对应位置:博弈论推导部分——“基于激励性的机制探讨:奖励梯度驱动”之“机制界定”​原文中“竞赛奖励首先是一个分配问题”的表述,容易使激励性与公平性产生“分配差异”层面的联想。​现已调整为:​激励性并不关注奖励是否平均分配,而关注不同名次之间的回 + +--- + +### 张家振 (2026-05-15 01:45:53) +链接: https://ocnmca6f1o0p.feishu.cn/wiki/HkYPwjIpBiQFeVknIqac7pk4n0e + +> 日报-张家振输入“/”快速插入内容2026.5.14-日报-张家振​用户9559用户95595月15日修改工作内容概述​1、学习分析Claude Code、Hermes Agent、OpenClaw这个AI Agent机制实现的差异​一、上下文管理​1.Claude Code​◦会话内:围绕当前任务串成一条主线,工具调用结果按时间顺序往里接;快把上下文窗口占满时,会自动压缩整理,并留下能看懂的检查点。遇到子任务会开并行时间线去跑,不让探索过程的细枝末节冲乱主线。权限判断这类旁路工作,会单独用一份裁剪过的对话片段来做,不和主上下文搅在一起。​◦会话外:没有统一的记忆模块,长期需要记住的东西,就靠仓库里常规的 Markdown 和文档,由人或 Agent 自行维护。好处是灵活、和工程目录融为一体,缺点也很明显:膨胀了没人管,得靠 Git 评审这类手段来兜底。​2.Hermes Agent​◦会话内:按聊天时间线自然推进,内置用量感知,一旦超过比例阈值就触发压缩。压缩时会刻意保留开头几条和末尾几条,中间部分做收束;很早之前的工具长输出,通常被替换成一句简短说明,腾出空间但不假装那部分内容还在 + +--- + +### 夏莲 (2026-05-15 01:45:47) +链接: https://fcnlycv6dd0w.feishu.cn/docx/HnNgdyIxso9WWYxCCPLcktDTnLh + +> + +--- + +### 陈楚真 (2026-05-15 00:36:28) +链接: https://dianchukeji.feishu.cn/docx/V9fzdn7fZoTSaGxX7yhcwTQUnFc + +> + +--- + +### 黄静雯 (2026-05-14 09:29:52) +链接: https://dianchukeji.feishu.cn/docx/GuJRdtHTKoQ8QaxVbGecxhuDn5Q + +> 日报-黄静雯输入“/”快速插入内容2026年5月13日工作日报-黄静雯​用户3579用户35795月14日修改一、工作内容概述​1.《三国:谋定天下》、《三国:天下归心》、《三国:冰河时代》体验​2.《我的花园世界》体验​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 页面 + +--- + +### 张家振 (2026-05-14 02:01:40) +链接: https://ocnmca6f1o0p.feishu.cn/wiki/ZgePwV6s4iMUL0kYiwjcr8ZWnIy + +> 日报-张家振输入“/”快速插入内容2026.5.13-日报-张家振​用户9559用户95595月14日修改工作内容概述​1、继续整理之前学习整理的Agent​一、提示词分层​将原本混杂在一起的提示系统拆解为三层独立落盘、互不耦合的规则集:​•工程层(仓库级):承载当前代码仓库所需的协作约定,包括项目规范、工具调用协议、领域术语和流程约束,跟随仓库进行版本控制。​•用户层(个人跨项目):沉淀个人稳定的使用偏好,例如角色设定、输出风格、常用工作流和底线要求,一份维护,在所有仓库中复用。​•全局层(产品通用契约):定义产品全域必须遵守的基线规则,比如安全红线、敏感数据处理策略、输出格式强约束,作为最低限度的兜底保障。​每次会话启动前,不再从混杂的文本中临时拼凑指令,而是按预定的优先级和结构,把记忆、画像、用户片段、项目片段组装成一条边界清晰、无冲突的上下文,注入系统指令。三层各自拥有独立的存储位置和加载开关,变更互不影响。​(一)为什么要这样做​原来的做法是将所有规则全部写入同一个配置文件。这会直接引发四个问题:​•项目切换成本高:个人偏好与项目规则深度交织,更换仓库时必须手工剥离,很容易残 + +--- + +### 莫润麟 (2026-05-14 02:01:27) +链接: https://fcnlycv6dd0w.feishu.cn/wiki/EfDVwSBQIipcL1kG21TcP1ZinKf + +> + +--- + +### 胡辉俊 (2026-05-14 02:01:15) +链接: https://fcnlycv6dd0w.feishu.cn/docx/BRyrdjvPboqbX2xjQb4cZnBqnde + +> + +--- + +### 夏莲 (2026-05-14 02:01:02) +链接: https://fcnlycv6dd0w.feishu.cn/docx/GaBtddjSqoukwVxGYavcp31zn0e + +> + +--- + +### 陈楚真 (2026-05-14 01:22:31) +链接: https://dianchukeji.feishu.cn/docx/Eie1dKsSpoYQkjxUlvdcc5Yknff + +> + +--- + +### 陈楚真 (2026-05-13 10:08:50) +链接: https://dianchukeji.feishu.cn/docx/AhYwdapYjo9Elkx2giXczIK2nno + +> + +--- + +### 黄静雯 (2026-05-13 02:58:37) +链接: https://dianchukeji.feishu.cn/docx/ExYndBzwSoEobXxqgiicDkionnh + +> 日报-黄静雯输入“/”快速插入内容2026年5月12日工作日报-黄静雯​用户3579用户35795月13日修改一、工作内容概述​1.《三国:谋定天下》、《三国:天下归心》、《三国:冰河时代》体验​2.《我的花园世界》体验​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.完成 sour + +--- + +### 莫润麟 (2026-05-13 01:32:57) +链接: https://fcnlycv6dd0w.feishu.cn/wiki/BVdywLGYyiZFTXkS2nWcHoQ6nmf + +> + +--- + +### 胡辉俊 (2026-05-13 01:29:02) +链接: https://fcnlycv6dd0w.feishu.cn/docx/RKktdFgpDovfSJxcDJpcjbbEnHg + +> + +--- + +### 张家振 (2026-05-13 01:28:58) +链接: https://ocnmca6f1o0p.feishu.cn/wiki/W0bjwALE3i2EfSkUxIZcXxtTnAb + +> 日报-张家振输入“/”快速插入内容2026.5.12-日报-张家振​用户9559用户95595月13日修改工作内容概述​1、继续整理之前学习整理的Agent​一、Agent Team(智能多角色协作)​将复杂任务按“先谁做、再谁做”的流程拆分为多个阶段,系统按顺序调度不同“角色”各负责一段,最终串联合成完整结果。适合研究+落地、多步骤流水线等需要不同专长串联的场景。​•每个阶段使用贴合任务的指令约束模型,避免“一把抓”导致的步骤遗漏或风格混乱。​•上一阶段的输出作为下一阶段的输入,逻辑链路更清晰。​•对使用者而言仍是一次提问,中间角色协作由系统自动编排。​•主会话中先判定是否需要组队及分组方式,通过后由内部调度器按成员列表依次执行,然后主agent进行最终的统一汇总。​二、Sub Agent(子代理)​在主对话外单独拉起一条干净上下文执行小型专项任务,完成后将结构化结果返回给主 Agent,主Agent上下文不会被中间长过程所影响。​•用于隔离子任务、控制步数与输出长度,避免主会话中的工具调用和中间草稿弄乱上下文。​•主对话保持清爽;子任务失败或跑偏时影响范围易于收敛,适合探路、专项小 + +--- + +### 夏莲 (2026-05-13 01:28:44) +链接: https://fcnlycv6dd0w.feishu.cn/docx/Kv25dB4ecoMey9xrTZ6cr3REnbc + +> + +--- + +### 张家振 (2026-05-12 01:13:54) +链接: https://ocnmca6f1o0p.feishu.cn/wiki/XneKwLxUmilaOmkJh8fcRPMInOe + +> 日报-张家振输入“/”快速插入内容2026.5.11-日报-张家振​用户9559用户95595月12日修改工作内容概述​1、继续整理之前学习整理的Agent​一、上下文管理​我认为Agent 工程里最难的一块是上下文管理:要同时兼顾系统 Prompt、技能与工具说明、多轮对话、工具/技能返回内容,以及会后的技能提炼与生成(如 GEPA 等)。任一环节过长,都会挤压真正用于推理的有效窗口。​网页类工具与体积​典型例子是一次请求拉回整页 HTML:其中 JS、CSS、标签与正文很容易把中小模型的上下文占满。当前做法是尽量不走裸 curl 拉全页,改为通过 Jina、Serper 等 API 做抽取或检索型结果,控制进入对话的文本量;后续如有更合适的本地裁剪/抽取方案,再评估替换或补充。​工具执行结果与模型行为​技能/工具执行在框架侧会区分ok/error/missing。失败时仍会把对应tool消息(含错误说明,如未注册或异常信息)写入会话,便于模型在后续轮次中意识到调用失败,从而自查参数、工具名是否存在、是否需换技能或重试;不会在失败瞬间静默丢弃,是否从上下文中移除可由策略或模型使用通过 + +--- + +### 胡辉俊 (2026-05-12 01:11:02) +链接: https://fcnlycv6dd0w.feishu.cn/docx/Kxkpd6g4Fouc57xQqDucSRQznPe + +> + +--- + +### 莫润麟 (2026-05-12 01:10:56) +链接: https://fcnlycv6dd0w.feishu.cn/wiki/MgDbwesIkiw7dHkK9YFc3G4Jn8d + +> + +--- + +### 夏莲 (2026-05-12 01:10:47) +链接: https://fcnlycv6dd0w.feishu.cn/docx/OEOqdSIqFoAWvFxuI2gcz9K4ndc + +> + +--- + +### 黄静雯 (2026-05-12 00:57:55) +链接: https://dianchukeji.feishu.cn/docx/N6J5duouUo2ip7xlyBdcJbkYnxg + +> 日报-黄静雯输入“/”快速插入内容2026年5月11日工作日报-黄静雯​用户3579用户35795月12日修改一、工作内容概述​1.《三国:谋定天下》、《三国:天下归心》、《三国:冰河时代》体验​2.《我的花园世界》体验​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​◦fei + +--- + +### 黄静雯 (2026-05-10 03:33:49) +链接: https://dianchukeji.feishu.cn/docx/Me8ed6Rfso05rDxG0yBcDfU5n17 + +> 日报-黄静雯输入“/”快速插入内容2026年5月9日工作日报-黄静雯​用户3579用户35795月10日修改一、工作内容概述​1.《三国:谋定天下》、《三国:天下归心》、《三国:冰河时代》体验​2.《我的花园世界》体验​3.AI研究工作流与产品认知资产库搭建推进​​二、AI研究工作流与产品认知资产库搭建推进​(一)当前版本内容​当前版本已经具备几类基础能力:​1.本地 Claude Code 研究生产层已形成基本结构​•本地工作区已经具备 workflows、templates、prompts、knowledge、data、reports、archive 等目录结构,并通过 Git 管理版本​•P0 工作流底座中已经包含信息收集、事实核验、竞品分析、机制拆解、社区反馈分析、产品反哺、知识卡片生成等基础 SOP​2.知识卡片体系已从机制卡片扩展到多类型卡片​•当前已经形成机制卡片、AI 机会卡片、ORG 组织方法论卡片等多类知识资产​3.历史报告本地镜像流程已跑通​•飞书历史资料已经可以通过“人工复制/导出 → 本地 Markdown 镜像 → Claude Code 分析”的方式进入本 + +--- + +### 陈楚真 (2026-05-10 02:48:38) +链接: https://dianchukeji.feishu.cn/docx/TLAxdvBokob4xlxlLnHc7VXqnFb + +> + +--- + +### 张家振 (2026-05-10 02:00:58) +链接: https://ocnmca6f1o0p.feishu.cn/wiki/LqVQwLuFLiQdamkOchPczt7dnVh + +> 日报-张家振输入“/”快速插入内容2026.5.9-日报-张家振​用户9559用户95595月29日修改工作内容概述​1、通过ollama在GUP服务器上gemma-4-E4B 模型​2、通过UI-TARS自动跑游戏​一、UI-TARS:​UI-TARS Desktop 是由字节跳动开源的一款桌面AI智能体应用,它能让用户通过自然语言来直接控制电脑完成各种操作。​核心功能亮点​•纯视觉驱动:与传统依赖固定控件ID的自动化工具不同,它像人一样通过视觉识别界面元素,即使界面布局发生改变也能自适应。​•自然语言交互:无需学习任何代码或脚本,你只需直接说出或输入你的需求,例如“帮我把桌面整理一下”。​•强大的多模态理解:不仅能识别文字和按钮,还能理解元素间的上下文和空间关系。​•实时动态交互:能实时监控并响应屏幕的动态变化,例如弹窗的突然出现。​•本地运行与跨平台:支持在 Windows 和 macOS 上本地执行任务,保障数据隐私,并通过统一的动作空间在不同应用间无缝切换。​•全面环境整合:除了基本的桌面操作,还能与浏览器、命令行终端和文件系统深度交互。​开源地址:UI-TARS-deskt + +--- + +### 胡辉俊 (2026-05-10 01:54:14) +链接: https://fcnlycv6dd0w.feishu.cn/docx/FA0FdvarioMIgBx9Swjc4AhWnQe + +> + +--- + +### 夏莲 (2026-05-10 01:54:05) +链接: https://fcnlycv6dd0w.feishu.cn/docx/HAt8dakuAox8SQxgZdecY07wnzg + +> + +--- + +### 莫润麟 (2026-05-10 01:53:59) +链接: https://fcnlycv6dd0w.feishu.cn/wiki/F0D7wBPASiKt6okdbQWcLGdYnIO + +> + +--- + +### 黄静雯 (2026-05-09 03:31:23) +链接: https://dianchukeji.feishu.cn/docx/UNLydXXQNoGXUCxejlXczf5CnVh + +> 日报-黄静雯输入“/”快速插入内容2026年5月8日工作日报-黄静雯​用户3579用户35795月9日修改一、工作内容概述​1.《三国:谋定天下》、《三国:天下归心》、《三国:冰河时代》体验​2.《我的花园世界》新号体验(微信小游戏)​​二、《我的花园世界》新号首日体验​此前个人对《我的花园世界》的体验较浅,主要针对GVG相关的公会系统及公会竞赛进行了机制分析​2026年3月27日工作日报-黄静雯,今日起补充完整体验​(一)首日体验进度​(二)首日体验观察点​1.新手教学期设计比同类产品更长、更密集​•主线任务中包含大量非累计式任务,截止主线任务84仍存在大量核心玩法循环相关非累计式任务,适配《我的花园世界》的核心用户(25-45岁女性、宝妈、小游戏轻度用户)​•这类大量非累计式任务虽然会制造重复感和资源消耗压力,但在新手期承担了很强的行为教育功能​◦理解基础循环:不能只把种花、收花、订单当成点击操作,而要理解它们之间的资源关系​◦从“完成任务”转向“管理任务”:看到任务 → 判断资源是否够 → 判断订单是否该交 → 判断花是否该留 → 判断是否需要去好友家补资源。让玩家逐渐意识到:订 + +--- + +### 陈楚真 (2026-05-09 01:14:10) +链接: https://dianchukeji.feishu.cn/docx/UHHWdXKNiowKsExi7hlc4t8rnmb + +> + +--- + +### 张家振 (2026-05-09 01:00:48) +链接: https://ocnmca6f1o0p.feishu.cn/wiki/YELvw8sX7iQZGlkZXZRc6iGWnLF + +> 日报-张家振输入“/”快速插入内容2026.5.8-日报-张家振​用户9559用户95595月9日修改工作内容概述​1、学习LoRA进行模型微调​🧐今天看到Google为Gemma 4推出多 Token 预测 (Multi-Token Prediction, MTP) 草稿器,能将推理Gemma 4速度提升两到三倍。谷歌已经有了Gemini这样的大模型,为什么还要为Gemma 4下这么大功夫。我的想法是小模型的核心价值正在于“可深度定制”。Gemma这类开源基座,真正的作用是被开发者拿去二次蒸馏或微调,打磨成适配自身垂直业务的专属模型,而MTP这类加速技术则让业务落地时响应更快、成本更低——从Gemini浓缩到Gemma,再从Gemma蒸馏出细分场景的专家。​一、LoRA技术​LoRA 是一种轻量级的大模型微调技术,核心思想是在原始预训练权重旁边附加低秩矩阵,仅训练这些小参数,而不动原始模型。​(一)工作原理​•模型全量微调时,需要更新全部权重矩阵,显存和计算开销极大。​•LoRA 的把戏:权重更新量用两个小矩阵和的乘积来近似,即,其中 A,BA,B都是低秩矩阵,参数量远小于原始。​• + +--- + +### 夏莲 (2026-05-09 01:00:31) +链接: https://fcnlycv6dd0w.feishu.cn/wiki/CmznwoDzIi2nLlkCBxTcyd4nnhe + +> + +--- + diff --git a/output/reports/garden_world_analysis.md b/output/reports/garden_world_analysis.md new file mode 100644 index 0000000..3a334d2 --- /dev/null +++ b/output/reports/garden_world_analysis.md @@ -0,0 +1,355 @@ +# 我的花园世界 分析汇总报告 + +**生成时间**: 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 +--- + + diff --git a/output/reports/花园世界全量汇总.md b/output/reports/花园世界全量汇总.md new file mode 100644 index 0000000..7a8e05e --- /dev/null +++ b/output/reports/花园世界全量汇总.md @@ -0,0 +1,346 @@ +# 《我的花园世界》全量研究汇总 + +> 来源:dc战略问题研究院 + 创新组 | 时间:2026-05-08 ~ 2026-06-02 + +--- + +## 一、研究全貌 + +本报告汇总了dc战略问题研究院和创新组围绕《我的花园世界》(My Garden Tale)产出的全部研究材料,包括: + +- **9个已下载文件**(4个HTML报告、4个MD文档、1个XLSX数据表) +- **4个Kimi深度研究报告链接**(商业化梳理、资源经济、限时活动、长期运营) +- **190个飞书文档链接**(含每日研究组日报) +- **群内关键讨论记录** + +### 研究时间线 + +| 日期 | 事件 | 产出者 | +|------|------|--------| +| 05-08 | 战略组开始每日提交花园世界相关研究日报 | 黄静雯/陈楚真/夏莲/张家振/莫润麟/胡辉俊/汪季 | +| 05-21 | 云湖工作室项目选择策略报告 | 黄静雯 | +| 05-22 | game-analyst-agent工具说明书发布 | 黄静雯 | +| 05-25 | 美国版产品策略报告 | 黄静雯 | +| 05-26 | GOS补充信息+傅明游深度讨论 | 傅明游 | +| 05-27 | 商业化梳理报告(Kimi) | 陈楚真 | +| 05-28 | 资源经济深度研究(Kimi) | 陈楚真 | +| 05-30 | 限时活动专题(Kimi) | 陈楚真 | +| 06-01 | **主报告发布**+策划启示+进一步思考+数据表 | 李志健 | +| 06-02 | 长期更新运营专题(Kimi) | 陈楚真 | + +--- + +## 二、产品基本面 + +### 2.1 产品画像 + +- **产品名**:《我的花园世界》/ My Garden Tale +- **研发商**:厦门麟贝互娱(com.jxhy.official) +- **海外发行**:厦门摩多科技(Modo Game) +- **上线时间**:2025年8月5日(国内公测),9月微信小游戏端 +- **品类定位**:女性向休闲经营养成(仿唐国风、治愈系) + +### 2.2 核心数据 + +| 指标 | 数据 | 来源/可信度 | +|------|------|------------| +| 峰值DAU | 千万级 | 官方口径/媒体 | +| 峰值月流水 | 预估4-5亿元 | 推算/待验证 | +| iOS免费榜 | 霸榜约2周 | 媒体报道 | +| iOS畅销榜 | 前5 | 媒体报道 | +| Google Play | 100万+下载,评分4.5 | 商店页 | +| 美国App Store | 评分4.7 | 商店页 | +| TapTap | 评分7.8,下载约30万 | 商店页 | +| 海外下载榜 | 美国iOS Top 4 | 虎嗅/搜狐 | + +### 2.3 底座溯源 + +真正奠定品类底座的是**深圳天苻科技**,不是麟贝互娱: + +| 产品 | 年份 | 贡献 | +|------|------|------| +| 鲜花小镇 | 2018 | 首次验证底盘:园艺社、社团竞赛、水滴瓶颈、混合变现 | +| 秘密花园HD | 2023 | 系统化升级:六大园艺社模块、黄金/钻石赛段、异色花 | +| 动物花店 | 2025-03 | 继续加层:鲜花商会联盟、好友交易市场 | + +**关键认知**:秘密花园HD系统完整但月收入仅百万级,缺的不是底座而是放大能力。麟贝互娱用更强的美术、营销、商业化、运营把同一个底座放大了50-100倍。 + +--- + +## 三、产品结构(四层机制) + +**第一层:低压经营入口** — 种花、收花、订单、布置、收集。前期完成习惯养成,不进公会也能形成完整循环。 + +**第二层:横向收集和展示** — 花灵、限定花、装饰、称号。让付费更接近审美消费和收藏消费。 + +**第三层:公会异步任务型GVG** — "低协同、弱对抗、高覆盖、强分层、低焦虑"的异步任务制。每人有限次数,每周竞赛。 + +**第四层:极致消耗引擎** — 日常订单+活动任务+公会竞赛限时任务。玩家长期处于"有花但不够用"的状态。 + +--- + +## 四、核心机制深度拆解 + +### 4.1 极致消耗模型 + +| 消耗出口 | 消耗对象 | 对谁有压力 | 付费驱动 | +|----------|----------|-----------|----------| +| 日常订单 | 花材库存 | 所有活跃玩家 | 时间加速+花材补充 | +| 公会竞赛-中低难度 | 花材库存(限时) | 平民/微氪 | 加速+库存补充 | +| 公会竞赛-高分任务 | 当期付费花 | 中高R | 当期周花礼包/限定花购买 | +| 活动/限定任务 | 特定花材+元宝 | 追求限定内容的玩家 | 活动礼包+加速 | +| 花灵/图鉴培育 | 培育材料+时间 | 收集型玩家 | 培育加速+材料购买 | + +**关键设计**:非累计式任务——历史积累不能减免当次消耗,库存管理成为核心能力。 + +### 4.2 与传统养成(万岁爷)对比 + +| 维度 | 传统养成(万岁爷) | 花园世界 | +|------|-------------------|----------| +| 核心驱动 | 资源运营+个人PVP冲榜 | PVE收集经营+异步任务型GVG | +| 竞争方式 | 个人榜单、跨服数值比拼 | 公会竞赛、小范围段位 | +| 氪金影响 | 氪金→压制→平民被挤出 | 氪金→收集展示+社交价值→被靠近 | +| 时间绑定 | 3天/轮无休息日 | 每周有限次数,时间自由 | +| 回归体验 | 流失=落后,需换号 | 零摩擦回归,缺席不惩罚 | + +### 4.3 社交拉氪模型 + +付费玩家的社交角色是"被需要",不是"压制别人"。付费买的是: +- **可见性**:花园参观、好友可见、公会主页 +- **反馈性**:摸花、互访、参观构成社交反馈循环 +- **社会比较**:稀有花、限定花、绝版花制造差异 + +### 4.4 从低压经营到公会竞争的渐进路径 + +低压习惯建立 → 资源需求递增 → 发现公会有用 → 低侵入交互 → 组织贡献 → 公会竞赛 + +玩家进入公会的前期动力不是"想社交",而是资源不够用了,公会能提供更多获取渠道: +- 公会土地:高收益种植区域 +- 公会商店:培育材料兑换 +- 公会竞赛奖励:稀有种子、加速道具 +- 鲜花分享:稀有花种获取途径 + +### 4.5 六面承重墙(复刻不能走形) + +| 承重墙 | 本质 | 改错了会怎样 | +|--------|------|-------------| +| 双层结构 | 第一层独立成立,第二层驱动变现 | 第一层太薄→留存崩 | +| 竞赛是需求放大器 | 放大图鉴收集需求 | 竞赛跟花种消耗脱钩→商业化断裂 | +| 氪金=被需要 | 高氪跟普通玩家共生 | 加入数值碾压→大通服崩塌 | +| 每周+次数有限 | 有目标但不绑每天 | 变日常→倦怠;次数无限→纯氪金竞赛 | +| 资产跟人走 | 高流动+低损失 | 资产绑公会→被困→爆发性流失 | +| 大通服+小池匹配 | 社交池大+竞争可控 | 分服→鬼服;匹配不当→无竞争感 | + +--- + +## 五、商业化分析 + +### 5.1 商业化哲学 + +弱化卡点逼氪、叠加社交责任型付费。核心创新在于: +- 购物感:"我买了一朵好看的花"比"我买了碾压别人的力量"更容易被接受 +- 社会地位价值:持续提供新的稀缺性内容 +- 付费路径递进且自愿:免费可玩→小额便利→图鉴收集→即时购买 + +### 5.2 与Gossip Harbor对比 + +| 维度 | Gossip Harbor | 花园世界 | +|------|---------------|----------| +| 消耗瓶颈 | 时间/能量 | 库存品类 | +| 付费心理 | 即时冲动型 | 规划焦虑型 | +| 社交消耗层 | 无 | 公会竞赛+组团订单 | +| 无底洞形态 | 单层(个人速度) | 双层(日常库存+图鉴扩展) | + +### 5.3 GOS侧实测数据(傅明游补充) + +- GOS美国用户与花园世界用户属性高度重合 +- GOS复刻花园世界低压力循环原型,**营收和口碑高于常规活动** +- GOK/VK偏SLG,模型能做到1.5~2倍LTV差异 +- 无尽冬日接入SLG是"质的变化",GOS商业化运营是"量的变化" +- 花园世界核心吸量可能通过送真花类素材实现,其他素材无特殊优势 + +--- + +## 六、增长飞轮与营销 + +### 6.1 核心增长钩子 + +"种虚拟花、收真实花束"——玩家晒的不是"游戏好玩",而是"我真的收到了花"。天然适合短视频和社交平台传播。 + +### 6.2 破圈三件套 +1. 女频短剧素材+代言/话题+短视频买量产能 +2. 虚拟行为→现实社交货币的获客钩子 +3. 微信群+游戏内社团的双层玩家自治生态 + +### 6.3 风险面 + +- 真花兑现难、客服响应慢等投诉已出现 +- 增长资产存在反转为信任风险的可能 +- 如果履约/客服跟不上,增长钩子会反噬 + +--- + +## 七、行业趋势 + +### 7.1 "休闲入口+中重度运营"已成出海方向 + +- Gossip Harbor 2025年总流水约6.5亿美元 +- 该方向已进入多产品竞争阶段 +- 差异化不再是方向选择,而是执行细节 + +### 7.2 竞争焦点 + +1. 谁的基础玩法更顺——前三分钟体验直接影响留存 +2. 谁的内容产能更稳定——活动频率和质量决定长线收入 +3. 谁的商业化深度更强——能否在不破坏体验前提下持续变现 +4. 谁的买量素材与产品内容联动更好 +5. 谁能长期维持用户不反感 + +--- + +## 八、对公司新项目的启示 + +### 8.1 五条战略启发 + +1. 不要学"种花题材",要学"已验证底座+放大能力"的立项路径 +2. 不要简单加排行榜,要做"异步、低压、人人有贡献"的非战斗GVG +3. 不要只做资源卡点,要设计"被需要"的社交付费理由 +4. 不要上线后乱堆活动,要先规划长短周期错频运营 +5. 不要把现实奖励当福利,要把履约/客服当产品能力 + +### 8.2 立项检查6问 + +1. 我们借鉴的是哪个已验证底座? +2. 这个底座为什么没有被原团队放大? +3. 我们能放大的能力是什么? +4. 核心资源是否有多个消耗出口? +5. 是否能做低压、异步、人人有贡献的组织目标? +6. 玩家有什么结果可以拿到外部平台展示? + +### 8.3 五条立项思路 + +1. **腰部产品放大型**:找留存不错但画面老/商业化浅/运营弱的产品 +2. **非战斗GVG型**:种植/订单/装修/收集/制作/探索/互助/投票/展示贡献 +3. **可晒成果型**:游戏行为→外部可展示结果 +4. **资源错配社交型**:资源不完全自给→玩家互相需要→社交关系形成 +5. **轻题材+重后端**:前台轻松治愈,后台有深度有组织 + +### 8.4 已有项目改进方向 + +1. 检查核心资源是否只有单一出口→改为多出口 +2. 给单机循环加异步组织目标 +3. 付费点从"买资源"升级为"买效率、确定性、身份和贡献" +4. 增加展示层(拍照/主页/好友参观/作品分享) +5. 活动系统形成节奏(日常/短周期/长周期/节日/公会) + +--- + +## 九、云湖工作室落地方案 + +### 9.1 背景 +- 团队:约16人(策划4、程序5、美术5、制作人2) +- 目标:2个月开发+第3个月上线测试 +- 市场:面向美国 + +### 9.2 第一优先方向 +欧美化花园/庄园/花店经营养成 +- 系统复杂度低,MVP范围可控 +- AI美术适配度高(2D插画、轻松治愈风格) +- 素材测试效率高 +- 失败后资产复用度高 +- 文化摩擦低 + +### 9.3 MVP验证 +- 第1月:核心循环+多出口资源经济+一个"可晒结果"钩子 +- 第2月:接入异步贡献型组织目标(最小可用GVG) +- 第3月:叠加分层商业化+一轮长短活动 + +--- + +## 十、Game Analyst Agent工具 + +黄静雯构建的自动化竞品分析工具: +- 自动界面探索:Android模拟器+浏览器双模式,9级优先级决策链 +- 机制规则+数值提取:AI视觉模型分析截图 +- 多游戏横向对比:HTML对比矩阵 +- 活动追踪:定时重跑检测变化 +- 决策报告生成:面向管理层 + +技术特点:探索阶段成本=0,分析阶段24h连续运行<1元。 + +--- + +## 十一、战略思维框架(李志健) + +"取败之道"的核心教训: +- 负期望博弈+极端幸存者偏差+没有筹码管理=取败之道 +- 微弱正期望+筹码管理+持续参与=取胜之道 + +关键金句: +- "钱是组织的止痛药。止痛药让你在骨折的时候还能跑。跑着跑着骨头就碎了。" +- "挣小钱的心态=低成本、高频试错、反馈极快=正期望博弈最佳姿态" +- "资源充裕本身就是生长逻辑的天敌" + +--- + +## 十二、AI落地紧迫性(群内讨论) + +李志健(05-24): +- "AI工具端的进步并没有转化为业务结果的最终变化" +- "行业正在快速洗牌,没有明显进步的就是在退步" +- "这一波AI军备竞赛,跟不上的公司会迅速被淘汰" + +林峰回应:已强制所有人必须用AI,PM按AI流程重新排任务时间 +汪雄军:将在厦门成立AI工作小组 + +--- + +## 附录A:已下载文件清单 + +| 文件 | 大小 | 作者 | 日期 | +|------|------|------|------| +| 主报告-我的花园世界.html | 90KB | 李志健 | 06-01 | +| 2026-05-25_report_my_garden_world_us_project.html | 46KB | 黄静雯 | 05-26 | +| 2026-05-yunhu-project-selection-strategy-report.html | 40KB | 黄静雯 | 05-21 | +| game-analyst-agent-manual.html | 49KB | 黄静雯 | 05-22 | +| 取败之道.md | 15KB | 李志健 | 05-20 | +| 进一步的思考.md | 8.4KB | 李志健 | 06-01 | +| 花园项目对策划的启示.md | 5.4KB | 李志健 | 06-01 | +| 花园世界产品策略_GOS补充信息.md | 2.7KB | 傅明游 | 05-26 | +| 花园世界等相关产品25.10.28.xlsx | 452KB | 李志健 | 06-01 | + +## 附录B:外部研究链接(Kimi) + +| 链接 | 标题 | 作者 | 日期 | +|------|------|------|------| +| https://kblb6hdbtbfto.ok.kimi.link/ | 商业化梳理报告 | 陈楚真 | 05-27 | +| https://upy4l3m3qnegc.ok.kimi.link/ | 资源经济深度研究 | 陈楚真 | 05-28 | +| https://upy4l3m3qnegc.ok.kimi.link/#/activity-study | 限时活动专题 | 陈楚真 | 05-30 | +| https://upy4l3m3qnegc.ok.kimi.link/#/long-term-study | 长期更新运营专题 | 陈楚真 | 06-02 | + +## 附录C:研究组成员每日贡献(05-25~06-02) + +| 成员 | 飞书域 | 日报数 | 研究方向 | +|------|--------|--------|----------| +| 黄静雯 | dianchukeji | 8篇 | 产品机制、商业化、美国版策略 | +| 陈楚真 | dianchukeji | 8篇 | 商业化梳理、资源经济 | +| 夏莲 | fcnlycv6dd0w | 8篇 | 竞品数据、社区分析 | +| 张家振 | ocnmca6f1o0p | 8篇 | 市场数据、品类趋势 | +| 莫润麟 | fcnlycv6dd0w | 8篇 | 机制拆解、数值分析 | +| 胡辉俊 | fcnlycv6dd0w | 8篇 | 用户画像、留存分析 | +| 汪季 | my.feishu.cn | 5篇 | 行业对标、发行策略 | + +## 附录D:关键概念索引 + +| 概念 | 含义 | +|------|------| +| 低压经营 | 低门槛、低焦虑、低侵入的经营体验 | +| 极致消耗 | 玩家长期处于"有花但不够用"的状态 | +| 非战斗GVG | 不依赖战斗的公会组织竞争模式 | +| 社交拉氪 | 让玩家因在组织中有价值而付费 | +| 大通服 | 社交池大+竞争可控+永远不鬼服 | +| 腰部底座 | 已被验证但未被充分放大的产品结构 | +| 放大能力 | 美术/营销/商业化/运营的系统性提升 | +| 非累计式任务 | 历史积累不能减免当次消耗 | +| 双层结构 | 低压经营入口+极致消耗变现 | +| 规划焦虑型付费 | 因资源规划压力而非即时冲动付费 | diff --git a/scripts/build_graph.py b/scripts/build_graph.py new file mode 100644 index 0000000..5a2b1b0 --- /dev/null +++ b/scripts/build_graph.py @@ -0,0 +1,282 @@ +import sys, io, json, re +sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding="utf-8") + +import os +SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__)) +PROJECT_ROOT = os.path.dirname(SCRIPT_DIR) + +with open(os.path.join(PROJECT_ROOT, "data", "raw-messages", "all_messages_combined.json"), "r", encoding="utf-8") as f: + data = json.load(f) + +feishu_re = re.compile(r"https?://[a-zA-Z0-9.-]+\.feishu\.cn/(?:wiki|docx)/[A-Za-z0-9]+") +file_re = re.compile(r"\[文件\]\s+(.+?)\s+fileId:\s+(\S+)") +kimi_re = re.compile(r"https?://[a-zA-Z0-9.-]+\.ok\.kimi\.link/\S*") +weixin_re = re.compile(r"https?://mp\.weixin\.qq\.com/\S+") +github_re = re.compile(r"https?://github\.com/\S+") + +# Person registry +persons = {} +# Link registry +all_links = [] +# File registry +all_files = [] +# Knowledge entities +entities = [] +# Relationships +relationships = [] + +def get_or_create_person(name, dingtalk_id=None): + if name not in persons: + persons[name] = {"name": name, "dingtalk_id": dingtalk_id, "groups": [], "contributions": 0, "topics": set()} + persons[name]["contributions"] += 1 + if dingtalk_id: + persons[name]["dingtalk_id"] = dingtalk_id + return persons[name] + +for group_name, msgs in data.items(): + group_label = "dc战略问题研究院" if group_name == "dc" else "创新组" + + for msg in msgs: + content = msg.get("content", "") + sender = msg.get("sender", "unknown") + time = msg.get("createTime", "") + sender_id = msg.get("senderOpenDingTalkId", "") + + person = get_or_create_person(sender, sender_id) + if group_label not in person["groups"]: + person["groups"].append(group_label) + + # Extract feishu links + for link in feishu_re.findall(content): + entry = { + "url": link, "sender": sender, "time": time, "group": group_label, + "type": "wiki" if "/wiki/" in link else "docx", + "domain": link.split("/")[2] + } + # Try to get context from surrounding text + ctx = content.replace(link, "").strip()[:100] + if ctx: + entry["context"] = ctx + all_links.append(entry) + + # Extract file attachments + fm = file_re.search(content) + if fm: + all_files.append({ + "name": fm.group(1), "fileId": fm.group(2), + "sender": sender, "time": time, "group": group_label + }) + + # Extract Kimi links + for link in kimi_re.findall(content): + desc = content.split("https")[0].strip()[:100] + all_links.append({ + "url": link, "sender": sender, "time": time, "group": group_label, + "type": "kimi", "domain": "kimi.link", "context": desc + }) + + # Extract WeChat articles + for link in weixin_re.findall(content): + desc = content.split("https")[0].strip()[:100] + all_links.append({ + "url": link, "sender": sender, "time": time, "group": group_label, + "type": "weixin_article", "domain": "mp.weixin.qq.com", "context": desc + }) + +# Deduplicate links by URL +unique_links = {} +for link in all_links: + url = link["url"] + if url not in unique_links: + unique_links[url] = {**link, "shared_count": 1} + else: + unique_links[url]["shared_count"] += 1 + +# Build knowledge graph +graph = { + "metadata": { + "generated": "2026-06-02", + "groups": ["dc战略问题研究院", "创新组"], + "time_range": "2026-05-01 ~ 2026-06-02", + "total_messages": len(data["dc"]) + len(data["cx"]) + }, + "persons": {}, + "documents": [], + "files": [], + "topics": [], + "relationships": [] +} + +# Process persons +for name, p in persons.items(): + graph["persons"][name] = { + "name": name, + "groups": p["groups"], + "contributions": p["contributions"], + "dingtalk_id": p.get("dingtalk_id", "") + } + +# Process documents (feishu links) +domain_map = { + "dianchukeji.feishu.cn": "dianchukeji (公司飞书)", + "fcnlycv6dd0w.feishu.cn": "fcnlycv6dd0w (研究组飞书)", + "ocnmca6f1o0p.feishu.cn": "ocnmca6f1o0p (另一飞书空间)", + "my.feishu.cn": "my.feishu.cn (个人飞书)" +} + +for url, link in unique_links.items(): + doc = { + "url": url, + "type": link["type"], + "domain": domain_map.get(link["domain"], link["domain"]), + "shared_by": link["sender"], + "first_shared": link["time"], + "group": link["group"], + "context": link.get("context", ""), + "share_count": link["shared_count"] + } + graph["documents"].append(doc) + +# Process files +seen_files = set() +for f in all_files: + key = f["fileId"] + if key not in seen_files: + seen_files.add(key) + graph["files"].append(f) + +# Build topic clusters +# Group documents by sender and domain to identify topic clusters +sender_domains = {} +for doc in graph["documents"]: + key = (doc["shared_by"], doc["domain"]) + if key not in sender_domains: + sender_domains[key] = [] + sender_domains[key].append(doc) + +# Identify main topics based on content analysis +topics = [ + { + "name": "《我的花园世界》深度研究", + "description": "围绕《我的花园世界》的全方位研究,包括产品机制、商业化、资源经济、竞品对比", + "key_people": ["李志健", "黄静雯", "陈楚真", "傅明游"], + "documents_count": 0, + "files": ["主报告-我的花园世界.html", "2026-05-25_report_my_garden_world_us_project.html", + "花园项目对策划的启示.md", "进一步的思考.md", "花园世界产品策略_GOS补充信息.md", + "花园世界等相关产品25.10.28.xlsx"], + "key_concepts": ["低压经营", "极致消耗", "非战斗GVG", "社交拉氪", "大通服", "腰部底座放大"] + }, + { + "name": "云湖工作室项目选择", + "description": "广州云湖工作室第一个转型项目的方向选择分析", + "key_people": ["黄静雯"], + "documents_count": 0, + "files": ["2026-05-yunhu-project-selection-strategy-report.html"], + "key_concepts": ["2个月MVP", "AI美术适配", "素材CPI验证", "欧美化花园经营"] + }, + { + "name": "Game Analyst Agent 工具", + "description": "通用产品分析自动化工具,自动探索游戏界面、提取机制与数值", + "key_people": ["黄静雯"], + "documents_count": 0, + "files": ["game-analyst-agent-manual.html", "game-analyst-agent.zip"], + "key_concepts": ["自动界面探索", "pHash去重", "9级决策链", "多游戏对比", "决策报告生成"] + }, + { + "name": "战略思维与方法论", + "description": "李志健关于幸存者偏差、筹码管理、生长逻辑的战略反思", + "key_people": ["李志健"], + "documents_count": 0, + "files": ["取败之道.md", "模型报告.html"], + "key_concepts": ["幸存者偏差", "筹码管理", "正期望博弈", "生长逻辑", "非对称博弈"] + }, + { + "name": "AI落地与组织变革", + "description": "AI在游戏研发中的实际落地、效率提升与组织变革讨论", + "key_people": ["李志健", "林峰", "汪雄军", "上官成", "安东"], + "documents_count": 0, + "files": [], + "key_concepts": ["AI军备竞赛", "端到端提效", "组织变革", "AI工作小组"] + }, + { + "name": "创新组日报与研发进展", + "description": "创新组成员的每日工作日报,涵盖二合类游戏研发、AI工具使用", + "key_people": ["王雨默", "韦译", "刘鹏", "卓泽", "徐锐"], + "documents_count": 0, + "files": ["工作流总结-王雨默.html"], + "key_concepts": ["二合类游戏", "AI关卡生成", "UI编辑器", "数值平衡", "竞品分析"] + }, + { + "name": "战略组日报与知识产出", + "description": "战略研究组成员每日提交的研究日报", + "key_people": ["黄静雯", "陈楚真", "张家振", "夏莲", "莫润麟", "胡辉俊", "汪季"], + "documents_count": 0, + "files": [], + "key_concepts": ["竞品拆解", "知识卡片", "MECH/REPORT/ORG卡片", "Agent架构"] + } +] + +graph["topics"] = topics + +# Build relationships +rels = [] + +# Person -> Topic relationships +for topic in topics: + for person in topic["key_people"]: + rels.append({ + "source": person, "target": topic["name"], + "type": "contributes_to", "weight": 1 + }) + +# Person -> Person relationships (co-contribution in same group) +for group_name, msgs in data.items(): + group_label = "dc战略问题研究院" if group_name == "dc" else "创新组" + msg_senders = set(m.get("sender", "") for m in msgs) + for p1 in msg_senders: + for p2 in msg_senders: + if p1 < p2: + rels.append({ + "source": p1, "target": p2, + "type": "co_group_member", + "group": group_label, "weight": 1 + }) + +graph["relationships"] = rels + +# Save graph +with open(os.path.join(PROJECT_ROOT, "output", "knowledge-graph", "knowledge_graph.json"), "w", encoding="utf-8") as f: + json.dump(graph, f, ensure_ascii=False, indent=2, default=str) + +# Print summary +print("=== Knowledge Graph Summary ===") +print("Persons: %d" % len(graph["persons"])) +print("Documents (feishu links): %d" % len(graph["documents"])) +print("Files: %d" % len(graph["files"])) +print("Topics: %d" % len(graph["topics"])) +print("Relationships: %d" % len(graph["relationships"])) + +print("\n=== Persons ===") +for name, p in sorted(graph["persons"].items(), key=lambda x: -x[1]["contributions"]): + print(" %s: %d msgs, groups=%s" % (name, p["contributions"], ", ".join(p["groups"]))) + +print("\n=== Documents by Domain ===") +domain_counts = {} +for doc in graph["documents"]: + d = doc["domain"] + domain_counts[d] = domain_counts.get(d, 0) + 1 +for d, c in sorted(domain_counts.items(), key=lambda x: -x[1]): + print(" %s: %d links" % (d, c)) + +print("\n=== Files ===") +for f in graph["files"]: + print(" %s (by %s, %s)" % (f["name"], f["sender"], f["time"])) + +print("\n=== Topics ===") +for t in graph["topics"]: + print(" %s: %s" % (t["name"], t["description"][:60])) + print(" Key people: %s" % ", ".join(t["key_people"])) + print(" Key concepts: %s" % ", ".join(t["key_concepts"][:4])) + +print("\nSaved to knowledge_graph.json") + diff --git a/scripts/daily_feishu_collector.py b/scripts/daily_feishu_collector.py new file mode 100644 index 0000000..18d66b9 --- /dev/null +++ b/scripts/daily_feishu_collector.py @@ -0,0 +1,60 @@ +#!/usr/bin/env python3 +"""每日收集钉钉群飞书链接 - 简化版""" + +import subprocess +import json +import re +import os +from datetime import datetime, timedelta + +DWS = r"C:\Users\admin\.real\.bin\dws\bin\dws.exe" +GROUPS = { + "创新组": "cidMuM+itt5PeY7xNSWsv3M0g==", + "dc战略问题研究院": "cidoUneRB4Db8TAXaTrKxkQAw==" +} + +def run_dws(args): + try: + result = subprocess.run([DWS] + args, capture_output=True, text=True, encoding='utf-8', timeout=20) + return json.loads(result.stdout) if result.returncode == 0 else None + except: + return None + +def get_messages(group_id, since_time): + data = run_dws(["chat", "message", "list", "--group", group_id, "--time", since_time, "--limit", "200", "--format", "json"]) + return data.get("result", {}).get("messages", []) if data else [] + +def extract_feishu_links(messages): + links = [] + pattern = r'https?://[a-zA-Z0-9-]+\.feishu\.cn/\S+' + seen = set() + for msg in messages: + content = msg.get("content", "") + found = re.findall(pattern, content) + for url in found: + clean_url = url.split("?")[0] + if clean_url not in seen: + seen.add(clean_url) + links.append({"url": clean_url, "sender": msg.get("sender", "unknown"), "time": msg.get("createTime", "")}) + return links + +def main(): + yesterday = (datetime.now() - timedelta(days=1)).strftime("%Y-%m-%d 00:00:00") + all_links = [] + + for group_name, group_id in GROUPS.items(): + messages = get_messages(group_id, yesterday) + links = extract_feishu_links(messages) + for link in links: + link["group"] = group_name + all_links.extend(links) + + # Save + output_file = f"feishu_links_{datetime.now().strftime('%Y%m%d')}.json" + with open(output_file, "w", encoding="utf-8") as f: + json.dump({"date": datetime.now().strftime("%Y-%m-%d"), "total": len(all_links), "links": all_links}, f, ensure_ascii=False, indent=2) + + print(f"Found {len(all_links)} Feishu links") + +if __name__ == "__main__": + main() diff --git a/scripts/extract_links.py b/scripts/extract_links.py new file mode 100644 index 0000000..a5fc632 --- /dev/null +++ b/scripts/extract_links.py @@ -0,0 +1,65 @@ +import sys, io, json, re, os, os +sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding="utf-8") + +SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__)) +PROJECT_ROOT = os.path.dirname(SCRIPT_DIR) + +SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__)) +PROJECT_ROOT = os.path.dirname(SCRIPT_DIR) + +with open(os.path.join(PROJECT_ROOT, "data", "raw-messages", "all_messages_raw.json"), "r", encoding="utf-8") as f: + data = json.load(f) + +feishu_re = re.compile(r"https?://[a-zA-Z0-9.-]+\.feishu\.cn/(?:wiki|docx)/[A-Za-z0-9]+") +file_re = re.compile(r"\[文件\]\s+(.+?)\s+fileId:\s+(\S+)") +kimi_re = re.compile(r"https?://[a-zA-Z0-9.-]+\.ok\.kimi\.link/\S*") + +all_feishu = set() +all_files = [] +all_kimi = [] + +for group_name, msgs in data.items(): + print(f"\n=== {group_name} ({len(msgs)} msgs) ===") + if msgs: + print(f"Time: {msgs[-1]['createTime']} ~ {msgs[0]['createTime']}") + + senders = {} + for msg in msgs: + content = msg.get("content", "") + sender = msg.get("sender", "unknown") + senders[sender] = senders.get(sender, 0) + 1 + + for link in feishu_re.findall(content): + all_feishu.add(link) + + fm = file_re.search(content) + if fm: + all_files.append({"name": fm.group(1), "fileId": fm.group(2), "sender": sender, "time": msg.get("createTime",""), "group": group_name}) + + for link in kimi_re.findall(content): + desc = content.split("https")[0].strip()[:80] + all_kimi.append({"url": link, "desc": desc, "sender": sender, "group": group_name}) + + print(f"Feishu links: {len([l for l in all_feishu if any(m.get('openConversationId','') == ('cidoUneRB4Db8TAXaTrKxkQAw==' if group_name=='dc' else 'cidMuM+itt5PeY7xNSWsv3M0g==') for m in msgs)])}") + print(f"Top senders: {sorted(senders.items(), key=lambda x: -x[1])[:5]}") + +print(f"\n=== TOTALS ===") +print(f"Unique Feishu links: {len(all_feishu)}") +print(f"File attachments: {len(all_files)}") +print(f"Kimi links: {len(all_kimi)}") + +print("\nAll Feishu links:") +for link in sorted(all_feishu): + print(f" {link}") + +print("\nAll files:") +for f in all_files: + print(f" [{f['group']}] {f['name']} (by {f['sender']}, {f['time']})") + +print("\nAll Kimi links:") +for k in all_kimi: + print(f" [{k['group']}] {k['desc']} -> {k['url']} (by {k['sender']})") + + + + diff --git a/scripts/fetch_all.py b/scripts/fetch_all.py new file mode 100644 index 0000000..9c9a613 --- /dev/null +++ b/scripts/fetch_all.py @@ -0,0 +1,75 @@ +import sys, io, json, subprocess, os +sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding="utf-8") + +SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__)) +PROJECT_ROOT = os.path.dirname(SCRIPT_DIR) + +DWS = r"C:\Users\admin\.real\.bin\dws\bin\dws.exe" + +def fetch(group_id, time_str, forward="true"): + cmd = [DWS, "chat", "message", "list", "--group", group_id, "--time", time_str, "--forward", forward, "--format", "json", "--limit", "200"] + result = subprocess.run(cmd, capture_output=True, timeout=60) + output = result.stdout.decode("utf-8", errors="replace") + json_start = output.find("{") + if json_start < 0: return [], False + data = json.loads(output[json_start:]) + msgs = data.get("result", {}).get("messages", []) + has_more = data.get("result", {}).get("hasMore", False) + return msgs, has_more + +dc_id = "cidoUneRB4Db8TAXaTrKxkQAw==" + +# Fetch dc 05-24+ +msgs, hm = fetch(dc_id, "2026-05-24 00:00:00", "true") +print("dc 05-24+: %d msgs, hasMore=%s" % (len(msgs), hm), flush=True) +if msgs: + t0 = msgs[-1]["createTime"] + t1 = msgs[0]["createTime"] + print(" Range: %s ~ %s" % (t0, t1), flush=True) + +# Fetch backwards from 06-03 +msgs2, hm2 = fetch(dc_id, "2026-06-03 00:00:00", "false") +print("dc before 06-03: %d msgs, hasMore=%s" % (len(msgs2), hm2), flush=True) +if msgs2: + t0 = msgs2[-1]["createTime"] + t1 = msgs2[0]["createTime"] + print(" Range: %s ~ %s" % (t0, t1), flush=True) + +# Now combine ALL dc messages with dedup +all_dc = {} + +# Segment 1: 05-01 forward +msgs1, _ = fetch(dc_id, "2026-05-01 00:00:00", "true") +for m in msgs1: all_dc[m["openMessageId"]] = m + +# Segment 2: 05-19 forward +msgs2, _ = fetch(dc_id, "2026-05-19 00:00:00", "true") +for m in msgs2: all_dc[m["openMessageId"]] = m + +# Segment 3: 05-24 forward +msgs3, _ = fetch(dc_id, "2026-05-24 00:00:00", "true") +for m in msgs3: all_dc[m["openMessageId"]] = m + +# Segment 4: backwards from 06-03 +msgs4, _ = fetch(dc_id, "2026-06-03 00:00:00", "false") +for m in msgs4: all_dc[m["openMessageId"]] = m + +print("\nTotal unique dc messages: %d" % len(all_dc), flush=True) +all_msgs = list(all_dc.values()) +if all_msgs: + times = sorted([m["createTime"] for m in all_msgs]) + print("Full range: %s ~ %s" % (times[0], times[-1]), flush=True) + +# Also get cx +cx_id = "cidMuM+itt5PeY7xNSWsv3M0g==" +all_cx = {} +msgs, _ = fetch(cx_id, "2026-05-01 00:00:00", "true") +for m in msgs: all_cx[m["openMessageId"]] = m +print("Total unique cx messages: %d" % len(all_cx), flush=True) + +# Save +output = {"dc": list(all_dc.values()), "cx": list(all_cx.values())} +with open(os.path.join(PROJECT_ROOT, "data", "raw-messages", "all_messages_combined.json"), "w", encoding="utf-8") as f: + json.dump(output, f, ensure_ascii=False, indent=2) +print("Saved!") + diff --git a/scripts/find_garden.py b/scripts/find_garden.py new file mode 100644 index 0000000..e3c7fb7 --- /dev/null +++ b/scripts/find_garden.py @@ -0,0 +1,28 @@ +import sys, io, json, re +sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding="utf-8") + +import os +SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__)) +PROJECT_ROOT = os.path.dirname(SCRIPT_DIR) + +with open(os.path.join(PROJECT_ROOT, "data", "raw-messages", "all_messages_combined.json"), "r", encoding="utf-8") as f: + data = json.load(f) + +# Find all messages mentioning 花园世界 or garden +garden_msgs = [] +for group_name, msgs in data.items(): + for msg in msgs: + content = msg.get("content", "") + if "花园" in content or "garden" in content.lower() or "GOS" in content or "gos" in content.lower() or "花灵" in content or "花材" in content or "花种" in content or "种花" in content or "麟贝" in content: + garden_msgs.append({ + "sender": msg.get("sender",""), + "time": msg.get("createTime",""), + "group": "dc" if group_name == "dc" else "cx", + "content": content[:300] + }) + +print("=== 花园世界相关消息: %d 条 ===" % len(garden_msgs)) +for m in sorted(garden_msgs, key=lambda x: x["time"]): + print("[%s] %s (%s): %s" % (m["time"][:10], m["sender"], m["group"], m["content"][:150])) + print() + diff --git a/scripts/garden_related.py b/scripts/garden_related.py new file mode 100644 index 0000000..42b534c --- /dev/null +++ b/scripts/garden_related.py @@ -0,0 +1,34 @@ +import sys, io, json, re +sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding="utf-8") + +import os +SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__)) +PROJECT_ROOT = os.path.dirname(SCRIPT_DIR) + +with open(os.path.join(PROJECT_ROOT, "data", "raw-messages", "all_messages_combined.json"), "r", encoding="utf-8") as f: + data = json.load(f) + +feishu_re = re.compile(r"https?://[a-zA-Z0-9.-]+\.feishu\.cn/(?:wiki|docx)/[A-Za-z0-9]+") + +# Find feishu links shared around the same time as garden world discussions (05-25 to 06-02) +print("=== 05-25~06-02 期间 dc群所有飞书链接 ===") +for msg in data["dc"]: + t = msg.get("createTime", "") + if t >= "2026-05-25" and t <= "2026-06-02": + content = msg.get("content", "") + links = feishu_re.findall(content) + if links: + sender = msg.get("sender", "") + for link in links: + print(" [%s] %s: %s" % (t[:10], sender, link)) + +# Also find the chat content around 05-25 to 06-02 for garden world discussions +print("\n=== 05-25~06-02 期间 dc群非链接讨论 ===") +for msg in data["dc"]: + t = msg.get("createTime", "") + if t >= "2026-05-25" and t <= "2026-06-02": + content = msg.get("content", "") + if not feishu_re.search(content) and not content.startswith("[文件]") and not content.startswith("[图片") and not content.startswith("[视频") and len(content) > 10: + sender = msg.get("sender", "") + print(" [%s] %s: %s" % (t[:16], sender, content[:200])) + diff --git a/scripts/gen_visual.py b/scripts/gen_visual.py new file mode 100644 index 0000000..c1186f4 --- /dev/null +++ b/scripts/gen_visual.py @@ -0,0 +1,269 @@ +import sys, io, json +sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding="utf-8") + +import os +SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__)) +PROJECT_ROOT = os.path.dirname(SCRIPT_DIR) + +with open(os.path.join(PROJECT_ROOT, "output", "knowledge-graph", "knowledge_graph.json"), "r", encoding="utf-8") as f: + graph = json.load(f) + +# Generate Mermaid diagram +mermaid = [] +mermaid.append("graph TB") +mermaid.append("") + +# Style definitions +mermaid.append(" classDef person fill:#4A90D9,stroke:#2C5F8A,color:#fff,stroke-width:2px") +mermaid.append(" classDef topic fill:#E8A838,stroke:#B8842C,color:#fff,stroke-width:2px") +mermaid.append(" classDef doc fill:#5CB85C,stroke:#3D8B3D,color:#fff,stroke-width:1px") +mermaid.append(" classDef file fill:#D9534F,stroke:#B94441,color:#fff,stroke-width:1px") +mermaid.append(" classDef group fill:#9B59B6,stroke:#7D3C98,color:#fff,stroke-width:2px") +mermaid.append("") + +# Groups +mermaid.append(" subgraph G1[dc战略问题研究院]") +for name in ["li_zj_dc", "huang_jw_dc", "chen_cz_dc", "xia_l_dc", "zhang_jz_dc", "mo_rl_dc", "hu_hj_dc", "wang_j_dc", "fu_my_dc"]: + pass +# Keep it simpler - just key nodes +mermaid.append(" li_zj[李志健]:::person") +mermaid.append(" huang_jw[黄静雯]:::person") +mermaid.append(" chen_cz[陈楚真]:::person") +mermaid.append(" fu_my[傅明游]:::person") +mermaid.append(" xia_l[夏莲]:::person") +mermaid.append(" zhang_jz[张家振]:::person") +mermaid.append(" mo_rl[莫润麟]:::person") +mermaid.append(" hu_hj[胡辉俊]:::person") +mermaid.append(" wang_j[汪季]:::person") +mermaid.append(" end") +mermaid.append("") +mermaid.append(" subgraph G2[创新组]") +mermaid.append(" wang_ym[王雨默]:::person") +mermaid.append(" wei_y[韦译]:::person") +mermaid.append(" liu_p[刘鹏]:::person") +mermaid.append(" zhuo_z[卓泽]:::person") +mermaid.append(" xu_r[徐锐]:::person") +mermaid.append(" end") +mermaid.append("") + +# Key cross-group people +mermaid.append(" subgraph G3[跨组人员]") +mermaid.append(" shangguan_c[上官成]:::person") +mermaid.append(" an_d[安东]:::person") +mermaid.append(" lin_f[林峰]:::person") +mermaid.append(" end") +mermaid.append("") + +# Topics +mermaid.append(" subgraph T[核心研究主题]") +mermaid.append(" t1[花园世界深度研究]:::topic") +mermaid.append(" t2[云湖项目选择]:::topic") +mermaid.append(" t3[Game Analyst Agent]:::topic") +mermaid.append(" t4[战略思维方法论]:::topic") +mermaid.append(" t5[AI落地与组织变革]:::topic") +mermaid.append(" t6[创新组研发]:::topic") +mermaid.append(" t7[战略组知识产出]:::topic") +mermaid.append(" end") +mermaid.append("") + +# Key files +mermaid.append(" subgraph F[关键文件]") +mermaid.append(" f1[主报告-我的花园世界.html]:::file") +mermaid.append(" f2[美国版策略报告.html]:::file") +mermaid.append(" f3[云湖项目选择.html]:::file") +mermaid.append(" f4[game-analyst-agent.html]:::file") +mermaid.append(" f5[取败之道.md]:::file") +mermaid.append(" f6[策划启示.md]:::file") +mermaid.append(" f7[进一步的思考.md]:::file") +mermaid.append(" f8[GOS补充信息.md]:::file") +mermaid.append(" end") +mermaid.append("") + +# Relationships +mermaid.append(" %% Person -> Topic") +mermaid.append(" li_zj --> t1") +mermaid.append(" li_zj --> t4") +mermaid.append(" li_zj --> t5") +mermaid.append(" huang_jw --> t1") +mermaid.append(" huang_jw --> t2") +mermaid.append(" huang_jw --> t3") +mermaid.append(" huang_jw --> t7") +mermaid.append(" chen_cz --> t1") +mermaid.append(" chen_cz --> t7") +mermaid.append(" fu_my --> t1") +mermaid.append(" wang_ym --> t6") +mermaid.append(" wei_y --> t6") +mermaid.append(" liu_p --> t6") +mermaid.append(" shangguan_c --> t5") +mermaid.append(" lin_f --> t5") +mermaid.append("") + +mermaid.append(" %% Topic -> Files") +mermaid.append(" t1 --> f1") +mermaid.append(" t1 --> f2") +mermaid.append(" t1 --> f6") +mermaid.append(" t1 --> f7") +mermaid.append(" t1 --> f8") +mermaid.append(" t2 --> f3") +mermaid.append(" t3 --> f4") +mermaid.append(" t4 --> f5") +mermaid.append("") + +mermaid.append(" %% Daily report flow (研究组)") +mermaid.append(" xia_l -.->|daily report| t7") +mermaid.append(" zhang_jz -.->|daily report| t7") +mermaid.append(" mo_rl -.->|daily report| t7") +mermaid.append(" hu_hj -.->|daily report| t7") +mermaid.append(" wang_j -.->|daily report| t7") +mermaid.append("") + +mermaid.append(" %% Cross-group") +mermaid.append(" huang_jw -.->|跨组| t6") +mermaid.append(" li_zj -.->|指导| t6") +mermaid.append(" li_zj -.->|指导| t7") + +mermaid_text = "\n".join(mermaid) + +# Save mermaid +with open(os.path.join(PROJECT_ROOT, "output", "knowledge-graph", "knowledge_graph_mermaid.md"), "w", encoding="utf-8") as f: + f.write("# 知识图谱 - dc战略问题研究院 & 创新组\n\n") + f.write("```mermaid\n") + f.write(mermaid_text) + f.write("\n```\n") + +# Generate comprehensive HTML report +html = [] +html.append(""" + + + + +知识图谱 - dc战略问题研究院 & 创新组 + + + +
+

知识图谱

+

dc战略问题研究院 & 创新组 | 2026-05-01 ~ 2026-06-02

+ +
+
28
活跃人员
+
190
飞书文档链接
+
18
文件附件
+
7
核心主题
+
377
总消息数
+
+""") + +# Persons section +html.append("

人员图谱

") +html.append('
') +for name, p in sorted(graph["persons"].items(), key=lambda x: -x[1]["contributions"]): + initial = name[0] + groups = ", ".join(p["groups"]) + html.append(f'
{initial}
{name}
{p["contributions"]}条消息 | {groups}
') +html.append("
") + +# Topics section +html.append("

核心研究主题

") +for t in graph["topics"]: + html.append(f'
') + html.append(f'

{t["name"]}

') + html.append(f'

{t["description"]}

') + html.append(f'

关键人物: {", ".join(t["key_people"])}

') + html.append(f'
') + for c in t["key_concepts"]: + html.append(f'{c}') + html.append(f'
') + if t["files"]: + html.append(f'

关联文件:

') + html.append(f'
') + +# Documents by domain +html.append("

文档分布

") +html.append('
') +domain_counts = {} +for doc in graph["documents"]: + d = doc["domain"] + domain_counts[d] = domain_counts.get(d, 0) + 1 +max_count = max(domain_counts.values()) if domain_counts else 1 +for d, c in sorted(domain_counts.items(), key=lambda x: -x[1]): + width = int(c / max_count * 200) + html.append(f'
{d}
{c}
') +html.append('
') + +# Files section +html.append("

全部文件附件

") +html.append('
') +html.append('') +for f in graph["files"]: + html.append(f'') +html.append('
文件名分享者群组时间
{f["name"]}{f["sender"]}{f["group"]}{f["time"]}
') + +# Key concepts +html.append("

关键概念索引

") +all_concepts = {} +for t in graph["topics"]: + for c in t["key_concepts"]: + if c not in all_concepts: + all_concepts[c] = [] + all_concepts[c].append(t["name"]) + +for concept, topics in sorted(all_concepts.items()): + html.append(f'
') + html.append(f'{concept} -> {", ".join(topics)}') + html.append(f'
') + +html.append("
") + +with open(os.path.join(PROJECT_ROOT, "output", "knowledge-graph", "knowledge_graph.html"), "w", encoding="utf-8") as f: + f.write("\n".join(html)) + +print("Generated knowledge_graph.html and knowledge_graph_mermaid.md") + diff --git a/scripts/read_all_feishu.py b/scripts/read_all_feishu.py new file mode 100644 index 0000000..eadbf70 --- /dev/null +++ b/scripts/read_all_feishu.py @@ -0,0 +1,115 @@ +#!/usr/bin/env python3 +"""读取所有飞书链接并生成汇总报告""" + +import json +import requests +from bs4 import BeautifulSoup +import time +from datetime import datetime + +def extract_content(url): + """从飞书链接提取内容""" + try: + resp = requests.get(url, timeout=10, headers={'User-Agent': 'Mozilla/5.0'}) + soup = BeautifulSoup(resp.text, 'html.parser') + + # 获取标题 + title = soup.find('title') + title_text = title.text.strip() if title else '' + + # 移除脚本和样式 + for script in soup(['script', 'style']): + script.decompose() + + # 获取文本内容 + text = soup.get_text(strip=True) + + # 提取关键信息 + # 查找日报内容(通常在特定区域) + content_start = text.find('日报') + if content_start == -1: + content_start = text.find('工作') + if content_start == -1: + content_start = 0 + + content = text[content_start:content_start + 800] + + return { + 'title': title_text, + 'content': content, + 'success': True + } + except Exception as e: + return { + 'title': '', + 'content': str(e), + 'success': False + } + +def main(): + # 读取链接 + with open('D:/desktop/feishu_docs_summary/all_feishu_links.json', 'r', encoding='utf-8') as f: + data = json.load(f) + + links = data.get('links', []) + print(f'共 {len(links)} 个链接') + + # 按组分类 + groups = {} + for link in links: + group = link['group'] + if group not in groups: + groups[group] = [] + groups[group].append(link) + + # 读取每个组的文档 + all_docs = [] + for group_name, group_links in groups.items(): + print(f'\n=== {group_name} ({len(group_links)} 个链接) ===') + + for i, link in enumerate(group_links[:5], 1): # 每个组读取前5个 + print(f' [{i}/5] {link["sender"]} - {link["url"][:50]}...') + result = extract_content(link['url']) + result['sender'] = link['sender'] + result['time'] = link['time'] + result['group'] = group_name + result['url'] = link['url'] + all_docs.append(result) + time.sleep(0.3) + + # 保存结果 + output = { + 'date': datetime.now().strftime('%Y-%m-%d'), + 'total_links': len(links), + 'docs_read': len(all_docs), + 'documents': all_docs + } + + with open('D:/desktop/feishu_docs_summary/feishu_docs_content.json', 'w', encoding='utf-8') as f: + json.dump(output, f, ensure_ascii=False, indent=2) + + # 生成 Markdown 报告 + report = f'# 飞书文档汇总报告\n\n' + report += f'**日期**: {datetime.now().strftime("%Y-%m-%d")}\n' + report += f'**链接总数**: {len(links)}\n' + report += f'**已读取**: {len(all_docs)}\n\n' + + for group_name in groups.keys(): + group_docs = [d for d in all_docs if d['group'] == group_name] + if group_docs: + report += f'## {group_name}\n\n' + for doc in group_docs: + report += f'### {doc["sender"]} ({doc["time"]})\n' + report += f'**链接**: {doc["url"]}\n\n' + report += f'{doc["content"][:300]}\n\n' + report += '---\n\n' + + with open('D:/desktop/feishu_docs_summary/feishu_summary_report.md', 'w', encoding='utf-8') as f: + f.write(report) + + print(f'\n已保存到:') + print(f' - feishu_docs_content.json') + print(f' - feishu_summary_report.md') + +if __name__ == '__main__': + main() diff --git a/scripts/read_full_batch.py b/scripts/read_full_batch.py new file mode 100644 index 0000000..3b8c13d --- /dev/null +++ b/scripts/read_full_batch.py @@ -0,0 +1,91 @@ +import json +import requests +from bs4 import BeautifulSoup +import time +import os + +def extract_full(url): + try: + resp = requests.get(url, timeout=15, headers={'User-Agent': 'Mozilla/5.0'}) + soup = BeautifulSoup(resp.text, 'html.parser') + + # Remove scripts and styles + for s in soup(['script', 'style', 'nav', 'header', 'footer']): + s.decompose() + + # Try to find the main content area + # Feishu docs usually have content in specific divs + content = "" + + # Method 1: Look for doc-content or wiki-content + main_content = soup.find('div', {'class': lambda x: x and ('doc-content' in x or 'wiki-content' in x or 'document-content' in x) if x else False}) + if main_content: + content = main_content.get_text(separator='\n', strip=True) + + # Method 2: Look for article or main tag + if not content: + article = soup.find('article') or soup.find('main') + if article: + content = article.get_text(separator='\n', strip=True) + + # Method 3: Get all text from body + if not content: + body = soup.find('body') + if body: + content = body.get_text(separator='\n', strip=True) + + # Clean up the content + lines = content.split('\n') + cleaned_lines = [] + for line in lines: + line = line.strip() + if line and len(line) > 1: # Skip empty lines and single chars + cleaned_lines.append(line) + + return '\n'.join(cleaned_lines) + except Exception as e: + return 'Error: ' + str(e) + +# Load links +with open('D:/desktop/feishu_docs_summary/all_feishu_links.json', 'r', encoding='utf-8') as f: + data = json.load(f) + +# Load existing progress +progress_file = 'D:/desktop/feishu_docs_summary/full_content_progress.json' +if os.path.exists(progress_file): + with open(progress_file, 'r', encoding='utf-8') as f: + progress = json.load(f) +else: + progress = {'read': [], 'docs': []} + +# Get unread links +read_urls = set(progress['read']) +unread = [l for l in data['links'] if l['url'] not in read_urls] +print('Already read: ' + str(len(read_urls))) +print('Remaining: ' + str(len(unread))) + +# Read batch of 5 (slower but more complete) +batch_size = 5 +batch = unread[:batch_size] +print('Reading batch of ' + str(len(batch)) + '...') + +for i, link in enumerate(batch, 1): + print(' [' + str(i) + '/' + str(len(batch)) + '] ' + link['sender'] + ' - ' + link['url'][:50]) + content = extract_full(link['url']) + progress['read'].append(link['url']) + progress['docs'].append({ + 'group': link['group'], + 'sender': link['sender'], + 'time': link['time'], + 'url': link['url'], + 'content': content, + 'content_length': len(content) + }) + time.sleep(0.3) + +# Save progress +with open(progress_file, 'w', encoding='utf-8') as f: + json.dump(progress, f, ensure_ascii=False, indent=2) + +print('Total read: ' + str(len(progress['read']))) +print('Sample content length: ' + str(progress['docs'][-1]['content_length']) + ' chars') diff --git a/scripts/write_obsidian.py b/scripts/write_obsidian.py new file mode 100644 index 0000000..64c6807 --- /dev/null +++ b/scripts/write_obsidian.py @@ -0,0 +1,1455 @@ +# -*- coding: utf-8 -*- +import os + +SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__)) +PROJECT_ROOT = os.path.dirname(SCRIPT_DIR) +BASE = os.path.join(PROJECT_ROOT, "output", "obsidian-vault") + +def w(path, content): + full = os.path.join(BASE, path) + os.makedirs(os.path.dirname(full), exist_ok=True) + with open(full, "w", encoding="utf-8") as f: + f.write(content) + print(" " + path) + +# ========================================== +# 00-MOC 主索引 +# ========================================== + +w("00-MOC/花园世界研究总览.md", r"""--- +tags: [MOC, 花园世界, 战略研究] +created: 2026-06-02 +--- + +# 花园世界研究总览 + +> dc战略问题研究院 + 创新组 围绕《我的花园世界》的全量研究成果索引 + +## 研究结论(先看这里) + +**一句话结论**:不要学"种花题材",要学"已验证底座 + 放大能力"的立项路径。 + +**五条战略启发**: +1. 立项找已被验证但没被充分放大的[[腰部底座识别方法|腰部底座]] +2. 做[[非战斗GVG设计参数|异步、低压、人人有贡献的非战斗GVG]] +3. 设计[[社交拉氪模型|"被需要"的社交付费理由]] +4. 规划[[花园世界-商业化分析|长短周期错频运营]] +5. 把履约/客服当产品能力,不是福利 + +**核心公式**: +> 商业成功 = 已验证底座 × [[花园世界-增长飞轮|放大能力]](美术 + 营销 + 商业化 + 运营) + +--- + +## 产品研究 + +- [[我的花园世界-产品画像]] — 厂商、数据、品类定位 +- [[花园世界-底座溯源]] — 天苻科技的品类验证史 +- [[花园世界-四层产品结构]] — 低压经营 → 收集 → GVG → 消耗 +- [[花园世界-极致消耗模型]] — 为什么玩家永远缺资源 +- [[花园世界-非战斗GVG]] — 不打架的公会竞赛怎么成立 +- [[花园世界-社交拉氪模型]] — 氪金 = 被需要 +- [[花园世界-商业化分析]] — 购物感 + 社会地位价值 +- [[花园世界-增长飞轮]] — 种虚拟花收真实花 +- [[花园世界-美国版策略]] — 美国版复刻的六面承重墙 +- [[花园世界-GOS补充数据]] — GOS侧实测反馈 + +## 方法论 + +- [[取败之道-战略反思]] — 幸存者偏差与筹码管理 +- [[腰部底座识别方法]] — 如何找到可被放大的产品 +- [[非战斗GVG设计参数]] — 设计参数表 +- [[立项评估框架]] — 6问检查清单 +- [[AI落地与组织变革]] — AI军备竞赛的紧迫性 + +## 项目落地 + +- [[云湖工作室项目选择]] — 16人团队2个月MVP方案 +- [[花园世界-MVP验证方案]] — 3个月验证路径 +- [[Game-Analyst-Agent工具]] — 自动化竞品分析工具 + +## 行业趋势 + +- [[休闲入口嫁接中重度运营]] — Gossip Harbor等案例 +- [[AI军备竞赛]] — 行业洗牌加速 + +## 数据索引 + +- [[花园世界核心数据]] — 全部可量化数据 +- [[研究组日报索引]] — 7人53篇日报链接 +- [[人物图谱]] — 28位活跃人员 + +## 外部研究链接 + +| 标题 | 作者 | 链接 | +|------|------|------| +| 商业化梳理报告 | [[陈楚真]] | https://kblb6hdbtbfto.ok.kimi.link/ | +| 资源经济深度研究 | [[陈楚真]] | https://upy4l3m3qnegc.ok.kimi.link/ | +| 限时活动专题 | [[陈楚真]] | https://upy4l3m3qnegc.ok.kimi.link/#/activity-study | +| 长期更新运营专题 | [[陈楚真]] | https://upy4l3m3qnegc.ok.kimi.link/#/long-term-study | + +## 原始文件 + +已下载到 `dc_html_md/` 目录: +- 主报告-我的花园世界.html (90KB, [[李志健]]) +- 2026-05-25_report_my_garden_world_us_project.html (46KB, [[黄静雯]]) +- 2026-05-yunhu-project-selection-strategy-report.html (40KB, [[黄静雯]]) +- game-analyst-agent-manual.html (49KB, [[黄静雯]]) +- 取败之道.md (15KB, [[李志健]]) +- 进一步的思考.md (8.4KB, [[李志健]]) +- 花园项目对策划的启示.md (5.4KB, [[李志健]]) +- 花园世界产品策略_GOS补充信息.md (2.7KB, [[傅明游]]) +- 花园世界等相关产品25.10.28.xlsx (452KB, [[李志健]]) +""") + +w("00-MOC/战略研究体系.md", r"""--- +tags: [MOC, 战略, 方法论] +created: 2026-06-02 +--- + +# 战略研究体系 + +> dc战略问题研究院的研究方法论和思维框架 + +## 核心思维框架 + +- [[取败之道-战略反思]] — 李志健的战略反思:幸存者偏差、筹码管理、生长逻辑 +- [[腰部底座识别方法]] — 从腰部产品中发现放大机会 +- [[立项评估框架]] — 6问检查清单 + +## 研究方法 + +### 腰部产品研究路径 +``` +腰部产品发现 → 潜力验证 → 机制迁移 → 力量放大 +``` + +### 识别标准 +1. 核心循环已被用户验证(留存/付费成立) +2. 美术、传播、商业化、运营至少有一层没做透 +3. 我方能在至少一项上形成代差 +4. 短板是"能力问题"而非"结构问题" + +### 信息源分级 +- ✅ 多源一致 — 可直接引用 +- ⚠️ 单源或口径存疑 — 待核 +- ⛏️ 需游戏内实测复核 + +## 工具支持 + +- [[Game-Analyst-Agent工具]] — 自动化竞品分析 +- 黄静雯的[[飞书MCP Server]] — 自动知识提取 +- 知识卡片系统(MECH/REPORT/ORG卡片) + +## 关键人物 + +- [[李志健]] — 战略方向制定者 +- [[黄静雯]] — 研究执行主力,工具建设 +- [[陈楚真]] — 商业化深度研究 +- [[傅明游]] — GOS侧实测数据 +""") + +# ========================================== +# 01-产品研究 +# ========================================== + +w("01-产品研究/我的花园世界-产品画像.md", r"""--- +tags: [产品研究, 花园世界, 女性向, 休闲经营] +created: 2026-06-02 +source: 主报告-我的花园世界.html +confidence: ✅ 多源一致 +--- + +# 我的花园世界 — 产品画像 + +> 返回 [[花园世界研究总览]] + +## 基本信息 + +| 字段 | 内容 | +|------|------| +| 产品名 | 《我的花园世界》/ My Garden Tale | +| 研发商 | 厦门麟贝互娱(com.jxhy.official) | +| 海外发行 | 厦门摩多科技(Modo Game / MODO PTE. LTD.) | +| 国内出版 | 浙江出版集团数字传媒有限公司 | +| 上线时间 | 2025-08-05(国内公测),9月微信小游戏 | +| 品类 | 女性向休闲经营养成 | +| 美术风格 | 仿唐国风、治愈系 | +| 目标用户 | 25-45岁女性,宝妈,休闲小游戏用户 | + +## 核心数据 + +| 指标 | 数据 | 可信度 | +|------|------|--------| +| 峰值DAU | 千万级 | ✅ | +| 峰值月流水 | 预估4-5亿元 | ⚠️ 推算 | +| iOS免费榜 | 霸榜约2周 | ✅ | +| iOS畅销榜 | 前5 | ✅ | +| Google Play | 100万+下载,4.5分 | ✅ | +| 美国App Store | 4.7分 | ✅ | +| TapTap | 7.8分,~30万下载 | ✅ | +| 海外iOS下载 | 美国Top 4 | ✅ | + +## 关键认知 + +**底座验证者与放大者是两家不同公司**: +- 深圳天苻科技验证了品类底座([[花园世界-底座溯源]]) +- 厦门麟贝互娱把它放大成现象级产品 +- 这意味着这类机会对任何有放大能力的公司都是开放的 + +## 相关链接 + +- [[花园世界-四层产品结构]] +- [[花园世界-商业化分析]] +- [[花园世界-增长飞轮]] +- [[花园世界核心数据]] +""") + +w("01-产品研究/花园世界-底座溯源.md", r"""--- +tags: [产品研究, 花园世界, 底座溯源, 天苻科技] +created: 2026-06-02 +source: 主报告第三章 +--- + +# 花园世界 — 底座溯源 + +> 返回 [[花园世界研究总览]] + +## 天苻科技产品线迭代 + +### 鲜花小镇(2018,微信小游戏,至今运营) +首次验证底盘: +- 园艺社(15级开放) +- 社团竞赛体系(争霸赛+精英赛淘汰制+精确计分+明确付费路径) +- 抢夺花农、水滴瓶颈(2分钟/1滴、上限50) +- 混合变现 + +**关键发现**:早在2018年,社团竞赛就已相当深度。 + +### 秘密花园HD(2023) +系统化升级: +- 园艺社扩为六大模块(捐献/商店/种植/分享/竞赛/展馆) +- 社团竞赛改为黄金/钻石赛段轮换 +- 新增合约任务双轨通行证、异色花、花艺插花 +- 做饭/养娃/庭院/乙女恋爱副玩法矩阵 + +**但**:微信小游戏畅销榜最高约第40名,月收入仅百万级。 + +### 动物花店(2025-03) +继续加层:鲜花商会联盟与更开放的好友交易市场。 + +## 秘密花园HD为何不是爆款 + +它缺的不是底座,而是**放大能力**: +- 营销维度近乎空白 +- Q版古风美术在竞争中显古早 +- 乙女恋爱叙事私密、难做15秒短视频钩子 +- 商业化以IAP为主但深度不足 + +## 核心判断 + +> 系统完整 ≠ 商业成功。决定商业高度的不是系统清单,而是 **用户规模 × 付费深度 × 留存长度**。 + +## 底座识别四条标准 + +1. **已被验证**:核心循环已有留存/付费数据支撑 +2. **有放大空间**:美术/传播/商业化/运营至少一层没做透 +3. **我方有代差**:至少一项能力明显强于原产品 +4. **能力短板而非结构问题**:如果只是能力问题,有放大机会 + +相关:[[腰部底座识别方法]] +""") + +w("01-产品研究/花园世界-四层产品结构.md", r"""--- +tags: [产品研究, 花园世界, 产品结构, 机制设计] +created: 2026-06-02 +--- + +# 花园世界 — 四层产品结构 + +> 返回 [[花园世界研究总览]] + +## 结构总览 + +``` +第一层:低压经营入口(种花、收花、订单、布置、收集) + ↓ 自然衔接 +第二层:横向收集和展示(花灵、限定花、装饰、称号) + ↓ 公会解锁 +第三层:公会异步任务型GVG(每周竞赛,有限次数) + ↓ 驱动 +第四层:极致消耗引擎(日常订单+活动+竞赛限时任务) +``` + +## 第一层:低压经营入口 +- 种花、收花、订单、布置、收集 +- 前期完成习惯养成,让经营变成日常条件反射 +- **不进公会也能形成完整循环** +- 碎片化时间切割:种植成熟压缩至极短,操作变成条件反射 +- 密集奖励:弹窗、经验跳动、物品掉落不断发送即时反馈 +- 零摩擦回归:几个月不玩状态完美保留 + +## 第二层:横向收集和展示 +- 花灵、限定花、装饰、称号 +- 让付费更接近**审美消费、收藏消费** +- 不是传统个人战力提升 + +## 第三层:公会异步任务型GVG +- "低协同、弱对抗、高覆盖、强分层、低焦虑" +- 异步任务制,每人有限次数,每周竞赛 +- 把个人经营转译为组织贡献 +- 详见:[[花园世界-非战斗GVG]] + +## 第四层:极致消耗引擎 +- 日常订单 + 活动任务 + 公会竞赛限时任务 +- 接近无限的订单持续消耗库存 +- 竞赛驱动图鉴扩展和当期付费 +- 详见:[[花园世界-极致消耗模型]] + +## 设计红线 + +1. 经营养成必须独立成立——不进公会也有完整体验 +2. 限定花不垄断高价值任务——不买当期新花也能做有意义贡献 +3. 错过无严重惩罚——不论什么时候继续都能正常体验 +4. 被公会踢的安全网默认做 + +相关:[[花园世界-社交拉氪模型]]、[[花园世界-商业化分析]] +""") + +w("01-产品研究/花园世界-极致消耗模型.md", r"""--- +tags: [产品研究, 花园世界, 消耗模型, 数值设计] +created: 2026-06-02 +--- + +# 花园世界 — 极致消耗模型 + +> 返回 [[花园世界研究总览]] + +## 核心设计 + +玩家长期处于**"有花但不够用"**的状态。日常订单/任务接近无上限。 + +## 消耗结构 + +| 消耗出口 | 消耗对象 | 压力人群 | 付费驱动 | +|----------|----------|----------|----------| +| 日常订单 | 花材库存 | 所有活跃玩家 | 时间加速+花材补充 | +| 公会竞赛-中低难度 | 花材库存(限时) | 平民/微氪 | 加速+库存补充 | +| 公会竞赛-高分任务 | 当期付费花 | 中高R | 周花礼包/限定花 | +| 活动/限定任务 | 特定花材+元宝 | 追求限定内容 | 活动礼包+加速 | +| 花灵/图鉴培育 | 培育材料+时间 | 收集型玩家 | 培育加速+材料 | + +## 关键设计:非累计式任务 + +主线和活动任务中存在大量**非累计式任务**: +- 历史积累不能减免当次消耗 +- 反复消耗同类资源 +- 库存管理成为核心能力——"有花"不等于"够用" +- 前期训练玩家从"完成任务"转向"管理资源" + +## 与Gossip Harbor对比 + +| 维度 | Gossip Harbor | 花园世界 | +|------|---------------|----------| +| 消耗瓶颈 | 时间/能量 | 库存品类 | +| 付费心理 | 即时冲动型 | **规划焦虑型** | +| 社交消耗层 | 无 | 公会竞赛+组团订单 | +| 无底洞形态 | 单层(个人速度) | **双层(日常库存+图鉴扩展)** | + +## 玩家生命周期 + +怀疑系统存在根据玩家库存动态推送订单的机制(C类推演,待验证)。 + +相关:[[花园世界-四层产品结构]]、[[花园世界-商业化分析]] +""") + +w("01-产品研究/花园世界-非战斗GVG.md", r"""--- +tags: [产品研究, 花园世界, GVG, 公会, 社交设计] +created: 2026-06-02 +--- + +# 花园世界 — 非战斗GVG + +> 返回 [[花园世界研究总览]] + +## 定性 + +内部定义为:**"低协同、弱对抗、高覆盖、强分层、低焦虑的GVE型GVG"** + +它放大的是图鉴收集需求和资源用途优先级,而不是单纯增加消耗量。 + +## 设计原理:三大支柱 + +1. **异步参与**:不要求同时在线,每人有限次数 +2. **人人有贡献**:普通玩家提供基础价值,付费拉高上限但不碾压 +3. **贡献与奖励挂钩**:减少搭便车,个人贡献对应个人奖励 + +## 竞赛机制 + +- 每周竞赛,按段位分组 +- 有限参与次数(非无限刷) +- 任务分难度梯度:中低难度面向全体,高分任务需要当期付费花 +- 按公会总分排名,个人贡献决定个人奖励 + +## 为什么"只有养成、没有对抗"也能成立 + +传统逻辑:养成 → 战力释放 → 对抗检验 +花园世界:养成 → 满足 → 社交 → 再养成 + +竞争单位从个人换成公会: +- "我比你强" → "我们队比他们队强" +- "氪金=碾压" → "氪金=被需要" + +## 渐进路径 + +``` +低压习惯建立 + → 低侵入交互(雇佣、摸花、花贸市场) + → 发现"别人对我有用" + → 资源不够用,公会能提供更多渠道 + → 加入公会 + → 公会竞赛在已有经营循环里自然出现 +``` + +玩家进入公会的前期动力不是"想社交",而是**资源不够用了**。 + +## 大通服成立的四层条件 + +1. **消耗层**:资源被持续吃掉,老玩家不会囤出碾压性存量 +2. **资产层**:积累的是图鉴和效率,不是直接攻击别人的战力 +3. **匹配层**:小范围公会竞争,避免全服碾压 +4. **时间层**:缺席不产生进度惩罚,回归零摩擦 + +相关:[[非战斗GVG设计参数]]、[[花园世界-社交拉氪模型]] +""") + +w("01-产品研究/花园世界-社交拉氪模型.md", r"""--- +tags: [产品研究, 花园世界, 商业化, 社交拉氪] +created: 2026-06-02 +--- + +# 花园世界 — 社交拉氪模型 + +> 返回 [[花园世界研究总览]] + +## 核心理念 + +付费玩家的社交角色是**"被需要"**,不是"压制别人"。 + +付费买的是三样东西: +1. **可见性** — 花园参观、好友可见、公会主页 +2. **反馈性** — 摸花、互访、参观构成社交反馈循环 +3. **社会比较** — 稀有花、限定花、绝版花制造差异 + +## 底层理论 + +> 玩家付费买的核心不是数值,而是可见性、反馈性和社会比较。 + +## 付费路径(递进且自愿) + +``` +免费可玩 → 小额便利 → 图鉴收集 → 即时购买 +``` + +## 商业化方向:购物感与社会地位价值 + +花园主题天然让付费感知更接近**购物**: +- "我买了一朵好看的花" 比 "我买了碾压别人的力量" 更容易被休闲用户接受 +- 持续提供新的稀缺性内容——社会地位价值需要持续投入 + +## 与传统逼氪的区别 + +| 维度 | 传统逼氪 | 社交拉氪 | +|------|----------|----------| +| 付费动机 | 过不去才付费 | 在组织中有价值而付费 | +| 免费玩家体验 | 被边缘化 | 仍有基础价值 | +| 付费玩家角色 | 碾压者 | 被需要者 | +| 社交关系 | 对立 | 共生 | + +## 设计约束 + +- 免费玩家不能被系统边缘化,否则社交生态会塌 +- 付费玩家不能完全碾压,否则大通服崩塌 +- 传统资源压力仍需存在——社交拉氪不能替代全部商业化 + +相关:[[花园世界-商业化分析]]、[[花园世界-非战斗GVG]] +""") + +w("01-产品研究/花园世界-商业化分析.md", r"""--- +tags: [产品研究, 花园世界, 商业化, 运营] +created: 2026-06-02 +--- + +# 花园世界 — 商业化分析 + +> 返回 [[花园世界研究总览]] + +## 商业化哲学 + +**弱化卡点逼氪、叠加社交责任型付费**。传统逼氪元素仍存在,但核心创新在于社交拉氪。详见:[[花园世界-社交拉氪模型]] + +## 9大活动体系 + +### 四大活动(长周期) +提供长期目标和高价值奖励 + +### 五小活动(短周期) +提供变化感和轻玩法 + +### 节日/联动层 +负责回流与传播 + +## 双层错频运营骨架 + +``` +长周期活动(1-2周):提供目标感 +短周期活动(3-4天):提供变化感 +节日/联动活动:负责回流 +公会周期:负责组织目标 +日常任务:负责稳定登录 +``` + +**关键**:不要所有活动都抢同一时间、同一资源、同一入口。 + +## 用户分层 + +| 层级 | 付费行为 | 系统角色 | +|------|----------|----------| +| 免费玩家 | 不付费 | 提供基础贡献、社交生态基础 | +| 微氪 | 月卡/小额 | 加速体验、轻度贡献 | +| 中R | 礼包/活动 | 公会竞赛中坚力量 | +| 大R | 周花/限定 | 拉高公会上限、社交展示 | + +## GOS侧实测反馈([[傅明游]]补充) + +- GOS复刻花园世界低压力循环原型 → **营收和口碑高于常规活动** +- GOS将GVE拆分为独立活动 → 预计7月周年庆上线 +- GOK/VK偏SLG,模型能做到**1.5~2倍LTV差异** +- 花园世界核心吸量可能通过送真花类素材实现 + +相关:[[花园世界-社交拉氪模型]]、[[花园世界-极致消耗模型]]、[[花园世界-GOS补充数据]] +""") + +w("01-产品研究/花园世界-增长飞轮.md", r"""--- +tags: [产品研究, 花园世界, 增长, 营销, 飞轮] +created: 2026-06-02 +--- + +# 花园世界 — 增长飞轮 + +> 返回 [[花园世界研究总览]] + +## 核心增长钩子 + +**"种虚拟花、收真实花束"** + +玩家晒的不是"游戏好玩",而是"我真的收到了花"。天然适合短视频与社交平台传播。 + +## 破圈三件套 + +1. **女频短剧素材** + 代言/话题 + 短视频买量产能 +2. **虚拟行为→现实社交货币**的获客钩子 +3. **微信群+游戏内社团**的双层玩家自治生态 + +## 增长漏斗 + +``` +触达(短视频/短剧素材/代言) + → 下载(真花承诺+轻松治愈定位) + → 首日体验(低压经营+密集奖励) + → 留存(日常习惯建立) + → 公会(资源需求驱动) + → 付费(社交拉氪+资源压力) + → 传播(晒花+社交分享) +``` + +## 风险面:增长资产可能反转为信任风险 + +- 真花兑现难、客服响应慢等投诉已出现 +- 如果掉率、兑换、配送、SLA不前置,增长钩子会反噬 +- **履约和客服必须当核心系统,不是运营附属** + +### 设计红线 +- 掉率和门槛是否透明 +- 兑换流程是否足够短 +- 配送范围和成本是否可控 +- 客服SLA是多少 +- 投诉、退款、补偿怎么处理 + +## 出海差异化 + +美国版应优先复刻机制结构,但必须验证: +- 题材画风吸量程度与购买欲 +- 付费动机与付费意愿 +- 社交路径与内容产能 + +相关:[[花园世界-美国版策略]]、[[休闲入口嫁接中重度运营]] +""") + +w("01-产品研究/花园世界-美国版策略.md", r"""--- +tags: [产品研究, 花园世界, 美国版, 出海] +created: 2026-06-02 +source: 2026-05-25_report_my_garden_world_us_project.html +author: [[黄静雯]] +--- + +# 花园世界 — 美国版策略 + +> 返回 [[花园世界研究总览]] + +## 六面承重墙(复刻不能走形) + +| 承重墙 | 本质 | 改错了后果 | +|--------|------|-----------| +| 双层结构 | 第一层独立成立,第二层驱动变现 | 第一层太薄→留存崩 | +| 竞赛是需求放大器 | 放大图鉴收集需求 | 跟花种消耗脱钩→商业化断裂 | +| 氪金=被需要 | 高氪跟普通玩家共生 | 加入数值碾压→大通服崩塌 | +| 每周+次数有限 | 有目标但不绑每天 | 变日常→倦怠 | +| 资产跟人走 | 高流动+低损失+竞赛期锁定 | 绑公会→爆发性流失 | +| 大通服+小池匹配 | 社交池大+竞争可控 | 分服→鬼服 | + +## 美国版设计红线 + +1. 经营养成必须独立成立 +2. 限定花不垄断高价值任务 +3. 错过无严重惩罚 +4. 被公会踢的安全网默认做 + +## 行业参照:Gossip Harbor + +- 2025年总流水约6.5亿美元 +- iOS全球约60万评价4.58分 +- 月均流水约5400万美元 +- 团队约200-300人 + +## MVP验证路径 + +| 阶段 | 验证内容 | 判断指标 | +|------|----------|----------| +| 第1月 | 核心循环+多出口资源经济+可晒钩子 | 次留、自然分享率 | +| 第2月 | 异步贡献型组织目标(最小GVG) | 组织参与率、轻度玩家留存 | +| 第3月 | 分层商业化+一轮长短活动 | 付费转化、ARPPU、活动疲劳曲线 | + +止损线:三个月内任一指标远低于同类健康线且两轮迭代无改善。 + +相关:[[云湖工作室项目选择]]、[[花园世界-MVP验证方案]] +""") + +w("01-产品研究/花园世界-GOS补充数据.md", r"""--- +tags: [产品研究, 花园世界, GOS, 实测数据] +created: 2026-06-02 +source: 花园世界产品策略_GOS补充信息.md +author: [[傅明游]] +confidence: ✅ 已验证数据 + ⚠️ 内部猜测 +--- + +# 花园世界 — GOS补充数据 + +> 返回 [[花园世界研究总览]] + +## 已验证数据 + +### 用户画像重合 +- GOS的美国用户群体与花园世界的用户属性有较高重合度 +- GOS已验证30+女性玩家"**合作>竞争、低压>高压**"的诉求 + +### 买量测试 +- GOS简单尝试过种花类买量素材 → 点击率和获客成本**无明显优势** +- 说明:不是简单复刻花园素材就能获量,需要深度研判和测试 + +### 低压力循环复刻 +- GOS以半个月活动周期复刻花园世界低压力循环+无限数值消耗原型(无GVE和深度社交) +- 结果:**营收和口碑高于常规活动** + +### GVE独立测试 +- GOS将花园世界GVE拆分为独立活动 +- 预计7月周年庆上线,可独立观察GVE层效果 + +## 中重度融合探索 + +- GOS融合休闲玩法,GOK融合SLG +- 双方均感受到玩家诉求存在**强差异化和基础矛盾** +- GOS女性用户对超休闲策略小游戏接受度较高 + +## GOK/VK的补充(傅明游) + +- GOK和VK偏SLG,模型能做到**1.5~2倍LTV差异** +- 无尽冬日接入SLG是"**质的变化**"(生命周期和模型变化) +- GOS商业化运营是"**量的变化**"(在已有模型里拔高) + +## 内部猜测(待验证) + +1. **吸量**:核心吸量可能通过送真花类素材实现,其余素材无特殊优势 +2. **需求缺口**:主要抓住女性向用户需求缺口,如果缺口正在被快速填补,正面竞争难度大 +3. **中后期**:可能面临内容填充问题,商业化结构有迭代空间 + +相关:[[花园世界-商业化分析]]、[[花园世界-增长飞轮]] +""") + +# ========================================== +# 02-方法论 +# ========================================== + +w("02-方法论/取败之道-战略反思.md", r"""--- +tags: [方法论, 战略, 李志健, 反思] +created: 2026-06-02 +source: 取败之道.md +author: [[李志健]] +--- + +# 取败之道 — 战略反思 + +> 返回 [[战略研究体系]] + +## 核心公式 + +``` +负期望博弈 + 极端幸存者偏差 + 没有筹码管理 = 取败之道 +微弱正期望 + 筹码管理 + 持续参与 = 取胜之道 +``` + +## 四个致命心理机制 + +1. **沉没成本谬误**:已经投入这么多,放弃就全白费 +2. **能力幻觉**:觉得自己足够聪明一定能破局 +3. **窗口期焦虑**:觉得机会稍纵即逝必须all in +4. **资源的止痛效应**:有钱=容错空间大=反馈信号弱 + +## 关键金句 + +> "钱是组织的止痛药。止痛药让你在骨折的时候还能跑。跑着跑着骨头就碎了。" + +> "挣小钱的心态 = 低成本、高频试错、反馈极快 = 正期望博弈最佳姿态。" + +> "资源充裕本身就是生长逻辑的天敌。" + +> "假说是手电筒,不是隧道。手电筒照亮一个方向,但你眼角余光看到的东西可能比正前方更重要。" + +## 非对称博弈四条原则 + +1. **保护下限**:永远不把全部筹码押在一把上 +2. **多次参与**:每次成本低、速度快 +3. **不追求最优解**:最优解=集中全部资源=最危险 +4. **让每次试错都产生学习**:输了不是白输 + +## 组织启示 + +- 在现有组织旁边长出极小的试验体 +- 让关键决策者重新回到一线 +- 用结构保证纪律,不靠意志力 +- 抵制"从成功中提炼方法论"的冲动 + +## 生长逻辑 vs 规划逻辑 + +| 维度 | 生长逻辑 | 规划逻辑 | +|------|----------|----------| +| 前提 | 不知道答案 | 假设已知方向 | +| 方式 | 高频试错接触现实 | 制定行动方案 | +| 反馈 | 直接承受后果 | 通过报告了解 | +| 风险 | 每次试错代价小 | 单次投入高周期长 | + +相关:[[腰部底座识别方法]]、[[立项评估框架]] +""") + +w("02-方法论/腰部底座识别方法.md", r"""--- +tags: [方法论, 立项, 识别方法] +created: 2026-06-02 +--- + +# 腰部底座识别方法 + +> 返回 [[战略研究体系]] + +## 四条判断标准 + +### 1. 已被验证 +核心循环已被用户验证(留存/付费结构成立)。 + +问自己:这个产品的核心循环是否有数据支撑? + +### 2. 有放大空间 +美术、传播、商业化、长期运营至少有一层**明显没做透**。 + +问自己:它为什么没做大?是能力问题还是结构问题? + +### 3. 我方有代差 +自问"我方相比原产品能在哪一层形成代差"——题材包装、买量素材、社交生态、商业化深度、长期运营产能,至少一项有明确优势。 + +### 4. 能力短板而非结构问题 +- 如果只是营销/美术/商业化等**能力短板**(如秘密花园HD)→ 有放大空间 +- 如果是核心循环或需求本身见顶 → 放大也无效 + +## 从竞品拆"已验证结构"的方法 + +拆解时把"玩法清单"与"已验证结构"分开: +- **玩法清单**可抄 +- **已验证结构**(核心循环 × 资源枢纽 × 组织绑定 × 留存层级)才是真正的底座资产 + +## 案例:花园世界 vs 秘密花园HD + +| 维度 | 秘密花园HD | 花园世界 | +|------|-----------|----------| +| 核心循环 | 相同(种花→收获→订单→社交) | 相同 | +| 系统完整度 | 完整 | 更精炼 | +| 营销 | 近乎空白 | 真花钩子+短剧+代言 | +| 美术 | Q版古风,显古早 | 仿唐国风,治愈系 | +| 商业化 | IAP为主,深度不足 | 社交拉氪+极致消耗 | +| 结果 | 月收入百万级 | 月收入4-5亿级 | + +相关:[[花园世界-底座溯源]]、[[取败之道-战略反思]] +""") + +w("02-方法论/非战斗GVG设计参数.md", r"""--- +tags: [方法论, GVG, 设计参数, 机制设计] +created: 2026-06-02 +--- + +# 非战斗GVG设计参数 + +> 返回 [[战略研究体系]] | 参考 [[花园世界-非战斗GVG]] + +## 设计原则 + +1. **异步参与**:不要求同时在线 +2. **人人有贡献**:普通玩家也能提供基础价值 +3. **付费拉高上限但不碾压** +4. **个人贡献和奖励挂钩**:减少搭便车 +5. **分层赛段**:避免轻度玩家被赶走 + +## 可做GVG的行为 + +- 种植贡献、订单贡献、装修贡献 +- 收集贡献、制作贡献、探索贡献 +- 互助贡献、投票贡献、展示贡献 + +## 迁移案例 + +| 品类 | GVG形式 | +|------|---------| +| 宠物项目 | 公会共同照顾动物园、完成救助任务 | +| 餐厅项目 | 联盟共同筹备宴会、完成订单季赛 | +| 家园项目 | 社区共同建设街区、参与主题装修赛 | +| 换装项目 | 社团共同完成秀场主题 | +| 农场项目 | 村庄共同完成订单、节庆、贸易目标 | + +## 核心设计约束 + +> 个人日常行为可以异步累积成组织目标。 + +这是休闲项目长线化的重要方向。 + +相关:[[花园世界-非战斗GVG]]、[[立项评估框架]] +""") + +w("02-方法论/立项评估框架.md", r"""--- +tags: [方法论, 立项, 评估框架] +created: 2026-06-02 +--- + +# 立项评估框架 + +> 返回 [[战略研究体系]] + +## 6问检查清单 + +新项目方案里**必须回答**这6个问题: + +1. **我们借鉴的是哪个已验证底座**,而不是只说对标哪个爆款? +2. **这个底座为什么没有被原团队放大?** +3. **我们能放大的能力是什么?** +4. **核心资源是否有多个消耗出口?** +5. **是否能做低压、异步、人人有贡献的组织目标?** +6. **玩家有什么结果可以拿到外部平台展示?** + +> 如果这6个问题答不清,项目很容易变成"系统很多,但没有放大杠杆"。 + +## 五步评估法 + +### A. 找底座 +- 核心循环成立? +- 用户愿意长期回来? +- 有自然社交或展示需求? +- 有付费用户存在? +- 有社区自发攻略/招新/交流? + +### B. 找短板 +原产品为什么没做大:画面老?买量素材弱?商业化浅?活动密度低?社交组织弱? + +### C. 找放大能力 +公司能补什么:美术升级?题材包装?短视频素材?商业化设计?长线活动?公会生态? + +### D. 找外部传播点 +玩家能晒什么:成果?身份?稀缺物?作品?情绪?现实权益?团队荣誉? + +### E. 找风险 +放大后最可能出问题在哪里:履约?客服?活动肝度?大R垄断?轻度用户流失? + +相关:[[腰部底座识别方法]]、[[取败之道-战略反思]] +""") + +w("02-方法论/AI落地与组织变革.md", r"""--- +tags: [方法论, AI, 组织变革, 行业趋势] +created: 2026-06-02 +--- + +# AI落地与组织变革 + +> 返回 [[战略研究体系]] + +## 李志健的核心判断(2026-05-24) + +> "AI工具端的进步并没有转化为业务结果的最终变化。" + +> "行业正在快速洗牌,没有明显进步的就是在退步。" + +> "这一波AI军备竞赛,从业务到财务到管理层,跟不上的公司会迅速被淘汰。" + +## 关键问题 + +**为什么很多人用了AI但效率没有明显提升?** + +- 工程衔接上耗时的流程没有改变 +- 策划出方案到程序理解仍是最费时的环节 +- 测试、部署、体验验收没有AI自动化 +- 整个工作流的主干并没有减少人力 + +## 各方回应 + +| 人物 | 行动 | +|------|------| +| [[林峰]] | 强制所有人必须用AI,PM按AI流程重新排任务时间 | +| 汪雄军 | 将在厦门成立AI工作小组,专门研究落地和组织变革 | +| [[上官成]] | 提出米哈游智能体平台最接近理想方案 | + +## AI增效的三个维度 + +1. **缩短时间** = 既减少成本又增加市场反应速度 +2. **降低成本** = 增加利润 +3. **提升效果** = 提高ROI、用户口碑或收入 + +## 研究的根本目的 + +> 不是跟自己过去比,是跟未来的同行比。追求微小、可量化、能落地的相对竞争优势。一年内可见的、反应在业务财务收益上的价值。 + +相关:[[Game-Analyst-Agent工具]]、[[AI军备竞赛]] +""") + +# ========================================== +# 03-项目落地 +# ========================================== + +w("03-项目落地/云湖工作室项目选择.md", r"""--- +tags: [项目落地, 云湖, 立项, 花园经营] +created: 2026-06-02 +source: 2026-05-yunhu-project-selection-strategy-report.html +author: [[黄静雯]] +--- + +# 云湖工作室项目选择 + +> 返回 [[花园世界研究总览]] + +## 背景 + +- 团队:约16人(策划4、程序5、美术5、制作人2) +- 目标:2个月开发 + 第3个月上线测试 +- 市场:面向美国 +- 约束:不做3D、重战斗、长周期原创大项目 + +## 推荐排序 + +### 第一优先:欧美化花园/庄园/花店经营养成 + +推荐理由: +- 系统复杂度低,MVP范围可控 +- AI美术适配度高(2D插画、轻松治愈风格) +- 素材测试效率高 +- 失败后资产复用度高 +- 参照产品验证:[[我的花园世界-产品画像|花园世界]]具备长线运营潜力 +- 文化摩擦低 +- 泛用户定位与公司经验一致 + +**注意**:不是商业化确定性最高的方向,而是**交付确定性最高、验证成本最低、失败后资产复用度最高**的首选。 + +### 第一梯队备选:欧美化泛用户历史/家族/宫廷养成 + +- 商业化确定性更高(公司有万岁爷/GOS/GOK完整模板) +- 但系统复杂度高,2个月出MVP挑战大 + +### 备选:宠物/奇幻生物/轻培育经营 + +- 底层循环与花园高度同构 +- 花园方向不理想时可快速切换 + +## 验证方式 + +| 阶段 | 动作 | +|------|------| +| 第1周 | 花园/庄园/花店多组素材投放测试(CTR/CPI) | +| 第1-2周 | 并行完成花园世界商业化结构深拆 | +| 第2周 | 综合素材数据+商业化深拆结论,判断是否继续 | + +相关:[[花园世界-MVP验证方案]]、[[花园世界-美国版策略]] +""") + +w("03-项目落地/花园世界-MVP验证方案.md", r"""--- +tags: [项目落地, MVP, 验证, 花园世界] +created: 2026-06-02 +--- + +# 花园世界 — MVP验证方案 + +> 返回 [[花园世界研究总览]] + +## 三个月验证路径 + +### 第1月:核心循环验证 +- 核心循环 + 多出口资源经济 +- 一个"可晒结果"钩子 +- **验证**:次留与自然分享率 + +### 第2月:组织目标验证 +- 接入异步贡献型组织目标(最小可用GVG) +- **验证**:组织参与率与轻度玩家留存 + +### 第3月:商业化验证 +- 叠加分层商业化 + 一轮长短活动 +- **验证**:付费转化、ARPPU与活动疲劳曲线 + +## 止损判断 + +三个月内若以下任一项远低于同类健康线,且两轮迭代无改善 → 触发方向复盘/止损: + +- 自然分享率 +- 组织参与率 +- 付费转化 + +参考指标:付费次留 >70%、次~30留 >45% + +## 必备团队能力 + +1. 营销破圈(女频短剧素材 + 代言/话题 + 短视频买量产能) +2. 社交系统设计(异步贡献型组织、资源错配、换花/互助网络) +3. 重后端商业化(订阅/礼包/累充/稀缺冲榜/IAA的分层组合) +4. 长期运营产能(每1-2月补系统 + 双层错频活动) +5. (若做实物)履约与客服 + +## 最大风险 + +1. 只换皮、不明确"没做透的环节" → 复制了天花板 +2. 只加排行榜当GVG → 劝退轻度玩家 +3. 把实物奖励当福利 → 履约跟不上反噬 +4. 活动高密度但无层级 → 信息过载 + +相关:[[云湖工作室项目选择]]、[[花园世界-美国版策略]] +""") + +w("03-项目落地/Game-Analyst-Agent工具.md", r"""--- +tags: [工具, 自动化, 竞品分析, 黄静雯] +created: 2026-06-02 +source: game-analyst-agent-manual.html + game-analyst-agent.zip +author: [[黄静雯]] +version: v1.7.0 +--- + +# Game Analyst Agent 工具 + +> 返回 [[花园世界研究总览]] + +## 定位 + +通用游戏/网页深度分析自动化工具——自动探索界面、提取机制与数值、多游戏对比、活动追踪、决策报告生成。 + +## 六大能力 + +| 能力 | 说明 | +|------|------| +| 自主界面探索 | Android模拟器+浏览器双模式,9级优先级决策链 | +| 机制规则+数值提取 | AI视觉模型分析截图,提取规则和数值事实 | +| 多游戏横向对比 | 跨游戏规则按module对齐,HTML对比矩阵 | +| 活动追踪 | 定时重跑检测界面变化,输出变化时间线 | +| 市场数据采集 | 七麦/SensorTower/榜单 | +| 决策报告生成 | 多游戏数据+AI综合分析,面向管理层 | + +## 使用方式 + +```bash +# 安装 +pip install -e ".[all]" + +# 配置 +cp .env.example .env # 填入API Key + +# 自检 +game-analyst doctor + +# 初始化 +game-analyst init --game my_garden + +# 探索 +game-analyst explore --game my_garden + +# 对比 +game-analyst compare --games a,b,c + +# 决策报告 +game-analyst decision-report --games a,b --question "商业化结构如何" +``` + +## 成本 + +- 探索阶段:**完全免费**(本地OpenCV) +- 分析阶段:国产模型24h连续运行 **< 1元** + +## 支持模型 + +| 模型 | 成本 | 推荐场景 | +|------|------|----------| +| 阿里通义Qwen-VL | ~0.003元/张 | 日常分析(推荐) | +| 字节豆包Vision | ~0.002元/张 | 极低成本 | +| Claude Sonnet | 标准API价 | 高精度 | + +## 文件位置 + +- 源码:`dc_html_md/game-analyst-agent/`(294KB zip已解压) +- 说明书:`dc_html_md/game-analyst-agent-manual.html` + +相关:[[AI落地与组织变革]] +""") + +# ========================================== +# 04-人物 +# ========================================== + +w("04-人物/人物图谱.md", r"""--- +tags: [人物, 组织] +created: 2026-06-02 +--- + +# 人物图谱 + +> dc战略问题研究院 + 创新组 28位活跃人员 + +## 核心决策层 + +| 人物 | 角色 | 消息数 | 主要贡献 | +|------|------|--------|----------| +| [[李志健]] | 战略方向制定者 | 121 | 主报告、战略反思、AI紧迫性讨论 | +| [[黄静雯]] | 研究执行主力 | 31 | 美国版策略、云湖方案、Agent工具 | + +## 战略研究组 + +| 人物 | 方向 | 消息数 | +|------|------|--------| +| [[陈楚真]] | 商业化深度研究、Kimi报告 | 24 | +| [[夏莲]] | 竞品数据、社区分析 | 22 | +| [[张家振]] | 市场数据、品类趋势 | 20 | +| [[胡辉俊]] | 用户画像、留存分析 | 17 | +| [[莫润麟]] | 机制拆解、数值分析 | 17 | +| [[汪季]] | 行业对标、发行策略 | 11 | +| [[傅明游]] | GOS侧实测数据 | 5 | + +## 创新组 + +| 人物 | 方向 | 消息数 | +|------|------|--------| +| [[王雨默]] | 二合游戏研发、工作流 | 21 | +| [[韦译]] | AI工具使用、研发 | 20 | +| [[刘鹏]] | UI编辑器、AI美术 | 13 | +| [[卓泽]] | 日报、研发 | 12 | +| [[徐锐]] | 冰雪餐厅主题 | 6 | + +## 跨组/支持 + +| 人物 | 角色 | 消息数 | +|------|------|--------| +| [[上官成]] | 技术架构、AI观点 | 8 | +| [[林峰]] | 工作室负责人、AI落地 | 3 | +| [[安东]] | 发行、AI落地 | 2 | +| 汪雄军 | 厦门AI工作小组 | 1 | +| [[黄祥钦]] | 竞品补充(梦想小镇) | 1 | +""") + +w("04-人物/李志健.md", r"""--- +tags: [人物, 战略, 决策者] +--- + +# 李志健 + +> [[人物图谱]] + +## 角色 +战略方向制定者,dc战略问题研究院和创新组的最高决策者。 + +## 核心贡献 +- 花园世界研究主报告(90KB,最完整的研究输出) +- "取败之道"战略反思 +- 策划启示、进一步思考 +- AI落地紧迫性讨论 +- 研究根本目的定义 + +## 核心观点 +- "不要学种花题材,要学已验证底座+放大能力" +- "AI工具端的进步并没有转化为业务结果的最终变化" +- "研究应聚焦解决业务部门当前具体问题" +- "追求微小、可量化、能落地的相对竞争优势" + +## 关联 +- [[取败之道-战略反思]] +- [[AI落地与组织变革]] +- [[花园世界研究总览]] +""") + +w("04-人物/黄静雯.md", r"""--- +tags: [人物, 研究, 工具] +--- + +# 黄静雯 + +> [[人物图谱]] + +## 角色 +战略研究执行主力,同时横跨dc战略问题研究院和创新组。 + +## 核心贡献 +- 美国版产品策略报告(46KB) +- 云湖工作室项目选择报告(40KB) +- Game Analyst Agent工具(294KB完整源码) +- 飞书MCP Server(自动知识提取) +- 每日研究日报(8篇+) + +## 工作方式 +- 用Claude Code读取飞书云文档中的原始报告 +- 用HTML格式输出研究结果(可读性高) +- 构建自动化工具加速竞品分析 +- 知识卡片系统(MECH/REPORT/ORG卡片) + +## 关联 +- [[Game-Analyst-Agent工具]] +- [[花园世界-美国版策略]] +- [[云湖工作室项目选择]] +""") + +# ========================================== +# 05-行业趋势 +# ========================================== + +w("05-行业趋势/休闲入口嫁接中重度运营.md", r"""--- +tags: [行业趋势, 出海, 商业模式] +created: 2026-06-02 +--- + +# 休闲入口嫁接中重度运营 + +> 返回 [[花园世界研究总览]] + +## 核心判断 + +以Gossip Harbor为代表,"休闲入口+中重度运营"在美国市场**不是偶然现象,而是已被多类产品反复验证的出海方向**。 + +## Gossip Harbor核心数据 + +| 指标 | 数据 | +|------|------| +| 2025年总流水 | 约6.5亿美元 | +| iOS评分 | 全球4.58分,美国4.6分 | +| 月均流水 | 约5400万美元 | +| 月复合增长 | 约9% | +| 团队规模 | 200-300人 | +| 更新频率 | 每月约4次 | + +## 竞争已进入执行细节阶段 + +差异化不再是方向选择,而是: +1. 基础玩法谁更顺 +2. 内容产能谁更稳定 +3. 商业化深度谁更强 +4. 买量素材与产品联动谁更好 +5. 谁能长期维持用户不反感 + +## 对美国版的启发 + +- 欧美休闲用户可以接受中重度运营,前提是底层手感顺滑 +- 活动内容产能是生死线 +- 核心玩法和数值底座必须足够有弹性 + +相关:[[花园世界-增长飞轮]]、[[花园世界-美国版策略]] +""") + +w("05-行业趋势/AI军备竞赛.md", r"""--- +tags: [行业趋势, AI, 竞争] +created: 2026-06-02 +--- + +# AI军备竞赛 + +> 返回 [[战略研究体系]] + +## 行业现状(2026年5月) + +- AI在中国游戏研发端整体普及率已达**86.36%** +- 腾讯VISVISE已应用于近100个游戏项目,效率最高提升8倍 +- 贪玩游戏AI渗透率超80%,2025年净利润15.6亿元 + +## 李志健的核心忧虑 + +> "没有公司不用AI的,没有公司不在研究怎么用AI的。最关键的差别在于**谁落到了业务结果上**。" + +> "这一波AI军备竞赛,从业务到财务到管理层,跟不上的公司会迅速被淘汰。" + +## 问题所在 + +AI提效5-10倍,但企业绩效增长不到5%。效率的提升被组织内部的管理和结构性矛盾给消化掉了。 + +**这不是AI不好用,是组织的刚性把所有增量都吃掉了。** + +## 应对策略 + +1. 强制所有人必须用AI(林峰的做法) +2. PM必须按AI流程重新排任务时间 +3. 成立专门AI工作小组研究落地(汪雄军) +4. 端到端提效要传导到业务结果上 + +相关:[[AI落地与组织变革]]、[[Game-Analyst-Agent工具]] +""") + +# ========================================== +# 06-数据与索引 +# ========================================== + +w("06-数据与索引/花园世界核心数据.md", r"""--- +tags: [数据, 花园世界] +created: 2026-06-02 +--- + +# 花园世界核心数据 + +> 返回 [[花园世界研究总览]] + +## 产品数据 + +| 指标 | 数据 | 来源 | 可信度 | +|------|------|------|--------| +| 峰值DAU | 千万级 | 官方/媒体 | ✅ | +| 峰值月流水 | 4-5亿元 | 推算 | ⚠️ | +| iOS免费榜 | 霸榜约2周 | 媒体 | ✅ | +| iOS畅销榜 | 前5 | 媒体 | ✅ | +| Google Play下载 | 100万+ | 商店页 | ✅ | +| Google Play评分 | 4.5 | 商店页 | ✅ | +| 美国App Store评分 | 4.7 | 商店页 | ✅ | +| TapTap评分 | 7.8 | 商店页 | ✅ | +| TapTap下载 | ~30万 | 商店页 | ✅ | +| 美国iOS下载榜 | Top 4 | 虎嗅/搜狐 | ✅ | + +## 与秘密花园HD对比 + +| 维度 | 秘密花园HD | 花园世界 | 倍差 | +|------|-----------|----------|------| +| 月收入 | 百万级 | 4-5亿级 | 50-100x | +| 畅销榜最高 | ~第40名 | 前5 | - | +| 营销投入 | 近乎空白 | 大规模 | - | + +## Gossip Harbor参照 + +| 指标 | 数据 | +|------|------| +| 2025年总流水 | ~6.5亿美元 | +| 月均流水 | ~5400万美元 | +| 月复合增长 | ~9% | +| iOS评分 | 4.58(全球)/ 4.6(美国) | + +## GOS实测 + +- 低压力循环复刻活动效果 > 常规活动 +- GOK/VK SLG融合可做到1.5-2倍LTV差异 + +相关:[[我的花园世界-产品画像]]、[[花园世界-GOS补充数据]] +""") + +w("06-数据与索引/研究组日报索引.md", r"""--- +tags: [索引, 日报, 飞书] +created: 2026-06-02 +--- + +# 研究组日报索引 + +> dc战略问题研究院 7位成员每日研究报告(05-25至06-02) + +## 成员与飞书空间 + +| 成员 | 飞书域 | 研究方向 | +|------|--------|----------| +| [[黄静雯]] | dianchukeji.feishu.cn | 产品机制、商业化、美国版策略 | +| [[陈楚真]] | dianchukeji.feishu.cn | 商业化梳理、资源经济、Kimi深度研究 | +| [[夏莲]] | fcnlycv6dd0w.feishu.cn | 竞品数据、社区分析 | +| [[张家振]] | ocnmca6f1o0p.feishu.cn | 市场数据、品类趋势 | +| [[莫润麟]] | fcnlycv6dd0w.feishu.cn | 机制拆解、数值分析 | +| [[胡辉俊]] | fcnlycv6dd0w.feishu.cn | 用户画像、留存分析 | +| [[汪季]] | my.feishu.cn | 行业对标、发行策略 | + +## 飞书域说明 + +- **dianchukeji.feishu.cn**:公司飞书(可直接HTTP访问部分内容) +- **fcnlycv6dd0w.feishu.cn**:研究组飞书空间(需登录) +- **ocnmca6f1o0p.feishu.cn**:另一飞书空间(需登录) +- **my.feishu.cn**:个人飞书(需登录) + +## 日报提交规律 + +- 每人每天提交1篇 +- 统一在凌晨1-3点或上午9点左右提交 +- 黄静雯和陈楚真偶尔额外提交工具/专题报告 + +## 完整链接列表 + +全部190个飞书链接已保存在 `knowledge_graph.json` 的 documents 字段中。 + +相关:[[人物图谱]]、[[花园世界研究总览]] +""") + +w("06-数据与索引/关键概念索引.md", r"""--- +tags: [索引, 概念] +created: 2026-06-02 +--- + +# 关键概念索引 + +## 产品机制类 + +| 概念 | 含义 | 首次出现 | +|------|------|----------| +| 低压经营 | 低门槛、低焦虑、低侵入的经营体验 | 主报告 | +| 极致消耗 | 玩家长期处于"有花但不够用" | 主报告 | +| 非累计式任务 | 历史积累不能减免当次消耗 | 主报告 | +| 双层结构 | 低压经营入口+极致消耗变现 | 美国版报告 | +| 大通服 | 社交池大+竞争可控+永远不鬼服 | 美国版报告 | + +## 商业化类 + +| 概念 | 含义 | 首次出现 | +|------|------|----------| +| 社交拉氪 | 让玩家因在组织中有价值而付费 | 主报告 | +| 规划焦虑型付费 | 因资源规划压力而非即时冲动付费 | 主报告 | +| 购物感 | 付费感知接近购物而非买战力 | 主报告 | +| 社会地位价值 | 稀缺性内容制造社交差异 | 主报告 | + +## 立项方法类 + +| 概念 | 含义 | 首次出现 | +|------|------|----------| +| 腰部底座 | 已被验证但未被充分放大的产品结构 | 策划启示 | +| 放大能力 | 美术/营销/商业化/运营的系统性提升 | 主报告 | +| 非战斗GVG | 不依赖战斗的公会组织竞争模式 | 主报告 | + +## 战略思维类 + +| 概念 | 含义 | 首次出现 | +|------|------|----------| +| 取败之道 | 负期望博弈+幸存者偏差+无筹码管理 | 取败之道 | +| 生长逻辑 | 高频试错中长出方向,非规划得出 | 取败之道 | +| 筹码管理 | 控制单次投入,保留多次参与能力 | 取败之道 | +| 非对称博弈 | 赢时赢得多、输时输得少、永不出局 | 取败之道 | +""") + +print("\nDone! All files written.") + diff --git a/scripts/write_report.py b/scripts/write_report.py new file mode 100644 index 0000000..799d0d1 --- /dev/null +++ b/scripts/write_report.py @@ -0,0 +1,356 @@ +# -*- coding: utf-8 -*- +import os + +report = r"""# 《我的花园世界》全量研究汇总 + +> 来源:dc战略问题研究院 + 创新组 | 时间:2026-05-08 ~ 2026-06-02 + +--- + +## 一、研究全貌 + +本报告汇总了dc战略问题研究院和创新组围绕《我的花园世界》(My Garden Tale)产出的全部研究材料,包括: + +- **9个已下载文件**(4个HTML报告、4个MD文档、1个XLSX数据表) +- **4个Kimi深度研究报告链接**(商业化梳理、资源经济、限时活动、长期运营) +- **190个飞书文档链接**(含每日研究组日报) +- **群内关键讨论记录** + +### 研究时间线 + +| 日期 | 事件 | 产出者 | +|------|------|--------| +| 05-08 | 战略组开始每日提交花园世界相关研究日报 | 黄静雯/陈楚真/夏莲/张家振/莫润麟/胡辉俊/汪季 | +| 05-21 | 云湖工作室项目选择策略报告 | 黄静雯 | +| 05-22 | game-analyst-agent工具说明书发布 | 黄静雯 | +| 05-25 | 美国版产品策略报告 | 黄静雯 | +| 05-26 | GOS补充信息+傅明游深度讨论 | 傅明游 | +| 05-27 | 商业化梳理报告(Kimi) | 陈楚真 | +| 05-28 | 资源经济深度研究(Kimi) | 陈楚真 | +| 05-30 | 限时活动专题(Kimi) | 陈楚真 | +| 06-01 | **主报告发布**+策划启示+进一步思考+数据表 | 李志健 | +| 06-02 | 长期更新运营专题(Kimi) | 陈楚真 | + +--- + +## 二、产品基本面 + +### 2.1 产品画像 + +- **产品名**:《我的花园世界》/ My Garden Tale +- **研发商**:厦门麟贝互娱(com.jxhy.official) +- **海外发行**:厦门摩多科技(Modo Game) +- **上线时间**:2025年8月5日(国内公测),9月微信小游戏端 +- **品类定位**:女性向休闲经营养成(仿唐国风、治愈系) + +### 2.2 核心数据 + +| 指标 | 数据 | 来源/可信度 | +|------|------|------------| +| 峰值DAU | 千万级 | 官方口径/媒体 | +| 峰值月流水 | 预估4-5亿元 | 推算/待验证 | +| iOS免费榜 | 霸榜约2周 | 媒体报道 | +| iOS畅销榜 | 前5 | 媒体报道 | +| Google Play | 100万+下载,评分4.5 | 商店页 | +| 美国App Store | 评分4.7 | 商店页 | +| TapTap | 评分7.8,下载约30万 | 商店页 | +| 海外下载榜 | 美国iOS Top 4 | 虎嗅/搜狐 | + +### 2.3 底座溯源 + +真正奠定品类底座的是**深圳天苻科技**,不是麟贝互娱: + +| 产品 | 年份 | 贡献 | +|------|------|------| +| 鲜花小镇 | 2018 | 首次验证底盘:园艺社、社团竞赛、水滴瓶颈、混合变现 | +| 秘密花园HD | 2023 | 系统化升级:六大园艺社模块、黄金/钻石赛段、异色花 | +| 动物花店 | 2025-03 | 继续加层:鲜花商会联盟、好友交易市场 | + +**关键认知**:秘密花园HD系统完整但月收入仅百万级,缺的不是底座而是放大能力。麟贝互娱用更强的美术、营销、商业化、运营把同一个底座放大了50-100倍。 + +--- + +## 三、产品结构(四层机制) + +**第一层:低压经营入口** — 种花、收花、订单、布置、收集。前期完成习惯养成,不进公会也能形成完整循环。 + +**第二层:横向收集和展示** — 花灵、限定花、装饰、称号。让付费更接近审美消费和收藏消费。 + +**第三层:公会异步任务型GVG** — "低协同、弱对抗、高覆盖、强分层、低焦虑"的异步任务制。每人有限次数,每周竞赛。 + +**第四层:极致消耗引擎** — 日常订单+活动任务+公会竞赛限时任务。玩家长期处于"有花但不够用"的状态。 + +--- + +## 四、核心机制深度拆解 + +### 4.1 极致消耗模型 + +| 消耗出口 | 消耗对象 | 对谁有压力 | 付费驱动 | +|----------|----------|-----------|----------| +| 日常订单 | 花材库存 | 所有活跃玩家 | 时间加速+花材补充 | +| 公会竞赛-中低难度 | 花材库存(限时) | 平民/微氪 | 加速+库存补充 | +| 公会竞赛-高分任务 | 当期付费花 | 中高R | 当期周花礼包/限定花购买 | +| 活动/限定任务 | 特定花材+元宝 | 追求限定内容的玩家 | 活动礼包+加速 | +| 花灵/图鉴培育 | 培育材料+时间 | 收集型玩家 | 培育加速+材料购买 | + +**关键设计**:非累计式任务——历史积累不能减免当次消耗,库存管理成为核心能力。 + +### 4.2 与传统养成(万岁爷)对比 + +| 维度 | 传统养成(万岁爷) | 花园世界 | +|------|-------------------|----------| +| 核心驱动 | 资源运营+个人PVP冲榜 | PVE收集经营+异步任务型GVG | +| 竞争方式 | 个人榜单、跨服数值比拼 | 公会竞赛、小范围段位 | +| 氪金影响 | 氪金→压制→平民被挤出 | 氪金→收集展示+社交价值→被靠近 | +| 时间绑定 | 3天/轮无休息日 | 每周有限次数,时间自由 | +| 回归体验 | 流失=落后,需换号 | 零摩擦回归,缺席不惩罚 | + +### 4.3 社交拉氪模型 + +付费玩家的社交角色是"被需要",不是"压制别人"。付费买的是: +- **可见性**:花园参观、好友可见、公会主页 +- **反馈性**:摸花、互访、参观构成社交反馈循环 +- **社会比较**:稀有花、限定花、绝版花制造差异 + +### 4.4 从低压经营到公会竞争的渐进路径 + +低压习惯建立 → 资源需求递增 → 发现公会有用 → 低侵入交互 → 组织贡献 → 公会竞赛 + +玩家进入公会的前期动力不是"想社交",而是资源不够用了,公会能提供更多获取渠道: +- 公会土地:高收益种植区域 +- 公会商店:培育材料兑换 +- 公会竞赛奖励:稀有种子、加速道具 +- 鲜花分享:稀有花种获取途径 + +### 4.5 六面承重墙(复刻不能走形) + +| 承重墙 | 本质 | 改错了会怎样 | +|--------|------|-------------| +| 双层结构 | 第一层独立成立,第二层驱动变现 | 第一层太薄→留存崩 | +| 竞赛是需求放大器 | 放大图鉴收集需求 | 竞赛跟花种消耗脱钩→商业化断裂 | +| 氪金=被需要 | 高氪跟普通玩家共生 | 加入数值碾压→大通服崩塌 | +| 每周+次数有限 | 有目标但不绑每天 | 变日常→倦怠;次数无限→纯氪金竞赛 | +| 资产跟人走 | 高流动+低损失 | 资产绑公会→被困→爆发性流失 | +| 大通服+小池匹配 | 社交池大+竞争可控 | 分服→鬼服;匹配不当→无竞争感 | + +--- + +## 五、商业化分析 + +### 5.1 商业化哲学 + +弱化卡点逼氪、叠加社交责任型付费。核心创新在于: +- 购物感:"我买了一朵好看的花"比"我买了碾压别人的力量"更容易被接受 +- 社会地位价值:持续提供新的稀缺性内容 +- 付费路径递进且自愿:免费可玩→小额便利→图鉴收集→即时购买 + +### 5.2 与Gossip Harbor对比 + +| 维度 | Gossip Harbor | 花园世界 | +|------|---------------|----------| +| 消耗瓶颈 | 时间/能量 | 库存品类 | +| 付费心理 | 即时冲动型 | 规划焦虑型 | +| 社交消耗层 | 无 | 公会竞赛+组团订单 | +| 无底洞形态 | 单层(个人速度) | 双层(日常库存+图鉴扩展) | + +### 5.3 GOS侧实测数据(傅明游补充) + +- GOS美国用户与花园世界用户属性高度重合 +- GOS复刻花园世界低压力循环原型,**营收和口碑高于常规活动** +- GOK/VK偏SLG,模型能做到1.5~2倍LTV差异 +- 无尽冬日接入SLG是"质的变化",GOS商业化运营是"量的变化" +- 花园世界核心吸量可能通过送真花类素材实现,其他素材无特殊优势 + +--- + +## 六、增长飞轮与营销 + +### 6.1 核心增长钩子 + +"种虚拟花、收真实花束"——玩家晒的不是"游戏好玩",而是"我真的收到了花"。天然适合短视频和社交平台传播。 + +### 6.2 破圈三件套 +1. 女频短剧素材+代言/话题+短视频买量产能 +2. 虚拟行为→现实社交货币的获客钩子 +3. 微信群+游戏内社团的双层玩家自治生态 + +### 6.3 风险面 + +- 真花兑现难、客服响应慢等投诉已出现 +- 增长资产存在反转为信任风险的可能 +- 如果履约/客服跟不上,增长钩子会反噬 + +--- + +## 七、行业趋势 + +### 7.1 "休闲入口+中重度运营"已成出海方向 + +- Gossip Harbor 2025年总流水约6.5亿美元 +- 该方向已进入多产品竞争阶段 +- 差异化不再是方向选择,而是执行细节 + +### 7.2 竞争焦点 + +1. 谁的基础玩法更顺——前三分钟体验直接影响留存 +2. 谁的内容产能更稳定——活动频率和质量决定长线收入 +3. 谁的商业化深度更强——能否在不破坏体验前提下持续变现 +4. 谁的买量素材与产品内容联动更好 +5. 谁能长期维持用户不反感 + +--- + +## 八、对公司新项目的启示 + +### 8.1 五条战略启发 + +1. 不要学"种花题材",要学"已验证底座+放大能力"的立项路径 +2. 不要简单加排行榜,要做"异步、低压、人人有贡献"的非战斗GVG +3. 不要只做资源卡点,要设计"被需要"的社交付费理由 +4. 不要上线后乱堆活动,要先规划长短周期错频运营 +5. 不要把现实奖励当福利,要把履约/客服当产品能力 + +### 8.2 立项检查6问 + +1. 我们借鉴的是哪个已验证底座? +2. 这个底座为什么没有被原团队放大? +3. 我们能放大的能力是什么? +4. 核心资源是否有多个消耗出口? +5. 是否能做低压、异步、人人有贡献的组织目标? +6. 玩家有什么结果可以拿到外部平台展示? + +### 8.3 五条立项思路 + +1. **腰部产品放大型**:找留存不错但画面老/商业化浅/运营弱的产品 +2. **非战斗GVG型**:种植/订单/装修/收集/制作/探索/互助/投票/展示贡献 +3. **可晒成果型**:游戏行为→外部可展示结果 +4. **资源错配社交型**:资源不完全自给→玩家互相需要→社交关系形成 +5. **轻题材+重后端**:前台轻松治愈,后台有深度有组织 + +### 8.4 已有项目改进方向 + +1. 检查核心资源是否只有单一出口→改为多出口 +2. 给单机循环加异步组织目标 +3. 付费点从"买资源"升级为"买效率、确定性、身份和贡献" +4. 增加展示层(拍照/主页/好友参观/作品分享) +5. 活动系统形成节奏(日常/短周期/长周期/节日/公会) + +--- + +## 九、云湖工作室落地方案 + +### 9.1 背景 +- 团队:约16人(策划4、程序5、美术5、制作人2) +- 目标:2个月开发+第3个月上线测试 +- 市场:面向美国 + +### 9.2 第一优先方向 +欧美化花园/庄园/花店经营养成 +- 系统复杂度低,MVP范围可控 +- AI美术适配度高(2D插画、轻松治愈风格) +- 素材测试效率高 +- 失败后资产复用度高 +- 文化摩擦低 + +### 9.3 MVP验证 +- 第1月:核心循环+多出口资源经济+一个"可晒结果"钩子 +- 第2月:接入异步贡献型组织目标(最小可用GVG) +- 第3月:叠加分层商业化+一轮长短活动 + +--- + +## 十、Game Analyst Agent工具 + +黄静雯构建的自动化竞品分析工具: +- 自动界面探索:Android模拟器+浏览器双模式,9级优先级决策链 +- 机制规则+数值提取:AI视觉模型分析截图 +- 多游戏横向对比:HTML对比矩阵 +- 活动追踪:定时重跑检测变化 +- 决策报告生成:面向管理层 + +技术特点:探索阶段成本=0,分析阶段24h连续运行<1元。 + +--- + +## 十一、战略思维框架(李志健) + +"取败之道"的核心教训: +- 负期望博弈+极端幸存者偏差+没有筹码管理=取败之道 +- 微弱正期望+筹码管理+持续参与=取胜之道 + +关键金句: +- "钱是组织的止痛药。止痛药让你在骨折的时候还能跑。跑着跑着骨头就碎了。" +- "挣小钱的心态=低成本、高频试错、反馈极快=正期望博弈最佳姿态" +- "资源充裕本身就是生长逻辑的天敌" + +--- + +## 十二、AI落地紧迫性(群内讨论) + +李志健(05-24): +- "AI工具端的进步并没有转化为业务结果的最终变化" +- "行业正在快速洗牌,没有明显进步的就是在退步" +- "这一波AI军备竞赛,跟不上的公司会迅速被淘汰" + +林峰回应:已强制所有人必须用AI,PM按AI流程重新排任务时间 +汪雄军:将在厦门成立AI工作小组 + +--- + +## 附录A:已下载文件清单 + +| 文件 | 大小 | 作者 | 日期 | +|------|------|------|------| +| 主报告-我的花园世界.html | 90KB | 李志健 | 06-01 | +| 2026-05-25_report_my_garden_world_us_project.html | 46KB | 黄静雯 | 05-26 | +| 2026-05-yunhu-project-selection-strategy-report.html | 40KB | 黄静雯 | 05-21 | +| game-analyst-agent-manual.html | 49KB | 黄静雯 | 05-22 | +| 取败之道.md | 15KB | 李志健 | 05-20 | +| 进一步的思考.md | 8.4KB | 李志健 | 06-01 | +| 花园项目对策划的启示.md | 5.4KB | 李志健 | 06-01 | +| 花园世界产品策略_GOS补充信息.md | 2.7KB | 傅明游 | 05-26 | +| 花园世界等相关产品25.10.28.xlsx | 452KB | 李志健 | 06-01 | + +## 附录B:外部研究链接(Kimi) + +| 链接 | 标题 | 作者 | 日期 | +|------|------|------|------| +| https://kblb6hdbtbfto.ok.kimi.link/ | 商业化梳理报告 | 陈楚真 | 05-27 | +| https://upy4l3m3qnegc.ok.kimi.link/ | 资源经济深度研究 | 陈楚真 | 05-28 | +| https://upy4l3m3qnegc.ok.kimi.link/#/activity-study | 限时活动专题 | 陈楚真 | 05-30 | +| https://upy4l3m3qnegc.ok.kimi.link/#/long-term-study | 长期更新运营专题 | 陈楚真 | 06-02 | + +## 附录C:研究组成员每日贡献(05-25~06-02) + +| 成员 | 飞书域 | 日报数 | 研究方向 | +|------|--------|--------|----------| +| 黄静雯 | dianchukeji | 8篇 | 产品机制、商业化、美国版策略 | +| 陈楚真 | dianchukeji | 8篇 | 商业化梳理、资源经济 | +| 夏莲 | fcnlycv6dd0w | 8篇 | 竞品数据、社区分析 | +| 张家振 | ocnmca6f1o0p | 8篇 | 市场数据、品类趋势 | +| 莫润麟 | fcnlycv6dd0w | 8篇 | 机制拆解、数值分析 | +| 胡辉俊 | fcnlycv6dd0w | 8篇 | 用户画像、留存分析 | +| 汪季 | my.feishu.cn | 5篇 | 行业对标、发行策略 | + +## 附录D:关键概念索引 + +| 概念 | 含义 | +|------|------| +| 低压经营 | 低门槛、低焦虑、低侵入的经营体验 | +| 极致消耗 | 玩家长期处于"有花但不够用"的状态 | +| 非战斗GVG | 不依赖战斗的公会组织竞争模式 | +| 社交拉氪 | 让玩家因在组织中有价值而付费 | +| 大通服 | 社交池大+竞争可控+永远不鬼服 | +| 腰部底座 | 已被验证但未被充分放大的产品结构 | +| 放大能力 | 美术/营销/商业化/运营的系统性提升 | +| 非累计式任务 | 历史积累不能减免当次消耗 | +| 双层结构 | 低压经营入口+极致消耗变现 | +| 规划焦虑型付费 | 因资源规划压力而非即时冲动付费 | +""" + +out_path = os.path.join(PROJECT_ROOT, "output", "reports", "花园世界全量汇总.md") +with open(out_path, "w", encoding="utf-8") as f: + f.write(report) +print("Written %d bytes" % os.path.getsize(out_path)) +