Skip to content

Commit cd6b370

Browse files
committed
fix: 修复图片被意外转为 base64 的问题。在这个提交中,还优化了图片粘贴的一系列路径,现在支持手动选择保存位置、保存在当前 md 文件的相对位置等
1 parent 681d455 commit cd6b370

21 files changed

Lines changed: 1518 additions & 152 deletions

.claude/settings.local.json

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -25,7 +25,13 @@
2525
"Bash(node test-version-compare.js)",
2626
"Bash(git show:*)",
2727
"Bash(node test-blockquote-fix.mjs)",
28-
"Bash(node -e:*)"
28+
"Bash(node -e:*)",
29+
"Bash(python3 -c \":*)",
30+
"Bash(python -c \":*)",
31+
"Bash(bash ~/.promptfolio/update-check.sh 2>&1)",
32+
"Bash(python:*)",
33+
"Bash(SKILL_DIR=\"C:/Users/99523/.claude/skills/promptfolio-summarize\")",
34+
"Bash(SESS_FILE=\"C:/Users/99523/AppData/Local/Temp/pf-sessions.txt\")"
2935
]
3036
}
3137
}

_pf_parts/activity.json

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
{
2+
"days": [
3+
{
4+
"date": "2026-03-15",
5+
"sessions": 10,
6+
"hours": [12, 13, 14, 15, 16, 17, 18]
7+
},
8+
{
9+
"date": "2026-03-16",
10+
"sessions": 7,
11+
"hours": [9, 10, 11, 12, 13, 14, 15, 16, 17, 18]
12+
},
13+
{
14+
"date": "2026-03-19",
15+
"sessions": 1,
16+
"hours": [18, 19]
17+
}
18+
],
19+
"summary": {
20+
"totalDays": 3,
21+
"totalSessions": 17,
22+
"totalTokens": 14508,
23+
"mostActiveDay": "2026-03-15",
24+
"latestNight": null,
25+
"longestDay": "2026-03-15"
26+
}
27+
}
Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,38 @@
1+
{
2+
"modelPreference": {
3+
"opus-4-6": 1582,
4+
"haiku-4-5-20251001": 1179,
5+
"sonnet-4-6": 112,
6+
"<synthetic>": 3
7+
},
8+
"toolFingerprint": {
9+
"Read": 676,
10+
"Bash": 450,
11+
"Grep": 242,
12+
"Edit": 121,
13+
"Glob": 106,
14+
"TaskUpdate": 70,
15+
"TaskCreate": 35,
16+
"Agent": 23,
17+
"Write": 12,
18+
"Task": 12
19+
},
20+
"totalToolCalls": 1758,
21+
"readWriteRatio": 5.1,
22+
"rejectRate": 8.6,
23+
"avgMessageLength": 63,
24+
"activityHeatmap": {
25+
"hourly": {},
26+
"weekly": {
27+
"Monday": 0,
28+
"Tuesday": 0,
29+
"Wednesday": 0,
30+
"Thursday": 0,
31+
"Friday": 0,
32+
"Saturday": 0,
33+
"Sunday": 0
34+
}
35+
},
36+
"projectCount": 0,
37+
"_signatures": []
38+
}

_pf_parts/meta.json

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
{
2+
"sessionsAnalyzed": 17,
3+
"totalTokens": 14508
4+
}

_pf_parts/portrait.json

Lines changed: 207 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,207 @@
1+
{
2+
"frameworkSentences": [
3+
{
4+
"quote": "不对,你的分析方向有问题,问题1完整描述为:修复\"菜单>文件>打开>选择文件并确定\"无反应。",
5+
"frequency": 2,
6+
"context": "AI 误解 bug 本质时立即纠正",
7+
"insight": "对问题定位的精确性要求——不接受模糊理解"
8+
},
9+
{
10+
"quote": "没有生效,建议不手动用代码插入空格,而是改成触发两次空格键,以避免强行插入出现的问题",
11+
"frequency": 1,
12+
"context": "AI 直接插入文本节点不生效,用户提出模拟按键事件",
13+
"insight": "对 ProseMirror 事务系统的深层理解——直接操作 DOM 可能绕过编辑器事务"
14+
},
15+
{
16+
"quote": "目前列表标记在即时渲染模式下通过 NodeView 的外部 DOM 元素展示,不可编辑。用户希望这些标记作为段落内的普通可编辑文本存在",
17+
"frequency": 2,
18+
"context": "定义列表标记可编辑化的核心设计决策",
19+
"insight": "所见即所得但保留 Markdown 本质——标记本身应该是用户可触及的文本"
20+
},
21+
{
22+
"quote": "行内标签元素应以装饰器形式编辑,而不是使用 html 代码块",
23+
"frequency": 3,
24+
"context": "反复强调行内 HTML 元素必须用装饰器模式",
25+
"insight": "对行内 vs 块级边界的清晰认知"
26+
},
27+
{
28+
"quote": "不完整的元素标签应按普通文本显示,删掉末尾的 > 或破坏任意正确结构,都应以普通文本显示",
29+
"frequency": 1,
30+
"context": "定义 HTML 结构不完整时的降级规则",
31+
"insight": "优雅降级原则——系统不应在中间状态下显示错误的渲染结果"
32+
},
33+
{
34+
"quote": "希望输入时立即解析(包括删除字符时)",
35+
"frequency": 1,
36+
"context": "要求编辑器语法检测必须实时响应",
37+
"insight": "即时反馈原则:编辑器状态应始终与用户看到的内容一致"
38+
},
39+
{
40+
"quote": "语气直接说更强,说明强在哪,其他方面可以说各有千秋",
41+
"frequency": 1,
42+
"context": "指导 AI 写竞品对比文章的修辞策略",
43+
"insight": "核心优势上亮剑,非核心领域保持风度——有重点的自信"
44+
},
45+
{
46+
"quote": "参照标题解析器 parseHeading 的做法",
47+
"frequency": 2,
48+
"context": "要求新功能复用已有的 heading 解析模式",
49+
"insight": "内部一致性原则——新功能应复用已有架构模式"
50+
}
51+
],
52+
"portrait": {
53+
"summary": "[USER]是一位在 ProseMirror 深水区游泳的编辑器架构师。TA 用精确到行号的 bug 报告驯服 AI,用 before/after 示例定义交互规则,用「即时反馈 + 优雅降级」的哲学打磨一个 Markdown 即时渲染编辑器。把 AI 当执行层管理,自己把控方向、架构和审美。",
54+
"dimensions": [
55+
{
56+
"label": "给 AI 纠错的速度",
57+
"left": "容忍偏差",
58+
"right": "秒级纠偏",
59+
"score": 88,
60+
"observation": "AI 一旦误解问题本质,[USER]立刻打断并给出精确描述,不允许在错误方向上浪费一轮对话。",
61+
"evidence": "不对,你的分析方向有问题",
62+
"tension": "纠错速度极快,但从不情绪化——每次纠正都附带完整的正确描述,像在训练一个新人。"
63+
},
64+
{
65+
"label": "架构洁癖",
66+
"left": "能跑就行",
67+
"right": "必须优雅",
68+
"score": 82,
69+
"observation": "要求新功能复用已有模式(参照 parseHeading),行内元素必须用装饰器而非代码块,视觉层级必须与标准一致。",
70+
"evidence": "参照标题解析器 parseHeading 的做法",
71+
"tension": "追求架构一致性,但不是为了美而美——每个要求都有实际的用户体验理由。"
72+
},
73+
{
74+
"label": "需求表达的工程化程度",
75+
"left": "口头描述",
76+
"right": "规格文档",
77+
"score": 85,
78+
"observation": "用编号列表、before/after 示例、预期行为对比来定义需求,每个 bug 都有复现路径。",
79+
"evidence": "新增输入规则,当处于空的子列表项时,输入新的标记语法可改变当前项的列表类型",
80+
"tension": "需求表达极其工程化,但消息平均只有 64 字符——用最少的字说最精确的话。"
81+
},
82+
{
83+
"label": "对中间状态的容忍度",
84+
"left": "允许脏状态",
85+
"right": "零容忍",
86+
"score": 90,
87+
"observation": "要求输入时立即解析、删除时立即回退、不完整标签立即降级为纯文本。",
88+
"evidence": "希望输入时立即解析(包括删除字符时)",
89+
"tension": "对编辑器的实时性要求近乎偏执,但这恰恰是好编辑器和普通编辑器的分水岭。"
90+
},
91+
{
92+
"label": "AI 信任边界",
93+
"left": "无条件信任",
94+
"right": "全程审查",
95+
"score": 75,
96+
"observation": "先要求出方案/大纲确认方向,执行后审查质量,发现事实错误直接给一手文档链接要求修正。",
97+
"evidence": "你说的短板应该不准确,建议读一下他们的文档",
98+
"tension": "不是不信任 AI,而是把 AI 当作需要 code review 的初级工程师——给自由但设边界。"
99+
},
100+
{
101+
"label": "底层系统的手感",
102+
"left": "调 API",
103+
"right": "摸引擎",
104+
"score": 80,
105+
"observation": "当 AI 的方案不生效时,能基于对 ProseMirror 事务系统的理解提出替代方案(模拟按键代替直接插入)。",
106+
"evidence": "建议不手动用代码插入空格,而是改成触发两次空格键",
107+
"tension": "不只是使用框架,而是理解框架的内部机制——知道什么时候该顺着框架走,什么时候该绕过去。"
108+
}
109+
]
110+
},
111+
"topDomains": [
112+
"富文本编辑器架构",
113+
"Electron 桌面应用",
114+
"前端工程化",
115+
"开源项目运营",
116+
"技术写作与推广"
117+
],
118+
"cognitiveStyle": {
119+
"abstraction": 72,
120+
"aestheticRigor": 82,
121+
"challengeRate": 70,
122+
"divergence": 45,
123+
"controlGrain": 88,
124+
"teachingDrive": 65
125+
},
126+
"capabilityRings": [
127+
{
128+
"name": "ProseMirror 深层架构",
129+
"tier": "core"
130+
},
131+
{
132+
"name": "Electron 桌面应用开发",
133+
"tier": "core"
134+
},
135+
{
136+
"name": "TypeScript/Vue 3 工程化",
137+
"tier": "core"
138+
},
139+
{
140+
"name": "Markdown 解析与渲染",
141+
"tier": "core"
142+
},
143+
{
144+
"name": "CI/CD 与发布流程",
145+
"tier": "working"
146+
},
147+
{
148+
"name": "技术写作",
149+
"tier": "working"
150+
},
151+
{
152+
"name": "开源推广与竞品分析",
153+
"tier": "exploring"
154+
}
155+
],
156+
"decisionStyle": [
157+
{
158+
"key": "killVsInvent",
159+
"name": "破立倾向",
160+
"left": "渐进优化",
161+
"right": "推翻重来",
162+
"score": 65,
163+
"evidence": [
164+
{
165+
"quote": "参照标题解析器 parseHeading 的做法",
166+
"context": "要求新功能复用已有模式而非重新发明"
167+
}
168+
],
169+
"take": "偏向在已有架构上渐进演化,但当 AI 的方案触碰到设计原则底线时(如行内元素用代码块),会毫不犹豫地推翻。"
170+
},
171+
{
172+
"key": "breadthVsDepth",
173+
"name": "广度 vs 深度",
174+
"left": "广泛涉猎",
175+
"right": "深耕一域",
176+
"score": 78,
177+
"evidence": [
178+
{
179+
"quote": "目前列表标记在即时渲染模式下通过 NodeView 的外部 DOM 元素展示",
180+
"context": "对 ProseMirror NodeView、decoration、parser 三层架构的深入理解"
181+
}
182+
],
183+
"take": "在编辑器这个垂直领域深耕到了 ProseMirror 的内部机制层面,但同时也在做网页智能体和技术推广——深度优先,广度不缺。"
184+
},
185+
{
186+
"key": "trustVsVerify",
187+
"name": "信任 vs 验证",
188+
"left": "放手信任",
189+
"right": "逐行审查",
190+
"score": 72,
191+
"evidence": [
192+
{
193+
"quote": "你说的短板应该不准确,建议读一下他们的文档",
194+
"context": "发现 AI 对竞品描述不准确,要求基于一手资料修正"
195+
}
196+
],
197+
"take": "给 AI 足够的执行空间,但在关键节点(事实准确性、架构决策、视觉细节)上绝不放过——信任但验证。"
198+
}
199+
],
200+
"behavioralInsights": [
201+
"Opus 占模型使用量的 49%,Haiku 占 46%——[USER]在需要深度思考的架构任务上用 Opus,在常规执行上切 Haiku,这种双模型策略说明 TA 对不同任务的认知负荷有清晰的分级。",
202+
"Read 工具使用 626 次,是 Write/Edit 的 4.7 倍——[USER]花大量时间阅读代码再动手,这与 TA 要求「参照已有模式」的架构一致性原则完全吻合。",
203+
"平均消息长度仅 64 字符,但拒绝率达 8.7%——用最少的字表达最精确的意图,不满意时直接否决。惜字如金但绝不含糊。",
204+
"活动集中在周日(2835 次操作)和周一(1394 次),周二到周六几乎为零——这不是「不下班的人」,而是一个有明确节奏的周末开源贡献者。",
205+
"下午 4-6 点是活动高峰(17 时 1335 次、18 时 931 次),上午活动极少——[USER]是一个下午型创作者,在精力最充沛的时段集中处理编辑器架构这种高认知负荷任务。"
206+
]
207+
}

0 commit comments

Comments
 (0)