从隐性投资经验到 AI 辅助决策系统的共创实践

今天，我和一位有多年股票投资经验的伙伴进行了一次交流，主题是怎样为她建立一套 AI 辅助的投资判断与决策系统。交流一开始，我没有直接进入工具安装或者系统开发，而是先询问她期待获得什么帮助。她当时对具体使用什么工具、怎样开始还没有清晰的概念，也提到此前尝试过一些工具，但实际体验并不理想。于是，我先把问题放在她希望实现的效果上，询问究竟什么样的系统才算好用。这成为后续讨论的起点。

对方最初描述的期待非常具体：输入一只股票的名称或代码，或者由系统按照固定时间自动运行，获取外围信息、个股信息和当日行情，再依据她预先提供的判断维度，生成相应的买卖建议。她举了上午 9:30、11:30 等时间作为例子，希望能够定时获得结果。至于结果是文字还是图片，她并没有特别要求。我把这个需求整理成输入、系统处理、输出三个部分：输入股票代码或名称；系统自动获取信息、读取既有判断维度、生成判断；最后以合适的形式输出，并增加定时机制。这一步让一个原本比较笼统的期待，开始形成可讨论的系统结构。

当我们讨论判断维度时，对方说明，她已经有一套基础，但还不能说完全确定，未来仍需要随着实际运行不断增加和调整。我因此提出，不能仅仅告诉 AI 有哪些判断维度，还需要把它们写成能够被理解和使用的协议。我们以 MACD 的收缩为例，讨论怎样定义某种特征、怎样识别特征、需要使用哪些数据，以及识别之后如何进入下一步判断。我用 If-Then 的方式说明规则之间的条件关系，对方则联想到 Excel 中的条件判断，以及测试题根据不同答案进入不同分支的逻辑。这样的交流帮助我们把投资者熟悉的判断方式，与系统可以执行的规则表达联系起来。

接下来，我们进一步明确协议文档的含义。对方最初不太理解，为什么 N 个判断维度的说明与协议有关。我解释，协议本身就是一个承载这些说明和关系的文档。它需要写明每个维度的名称、特点、特征、判断方式、所需数据，以及不同维度之间的关系。未来，当系统获得数据后，就可以为相应变量赋值，再根据多个变量之间的关系形成判断。这意味着，原本依靠投资者在脑海中综合处理的信息，需要被转化为明确的、可以反复调用的规则。对方听完之后表示，发现事情比自己原先想象的复杂，也意识到过去并没有把相关经验充分提炼出来。

讨论逐渐进入了更深一层的问题：为什么要把人的判断经验转化为系统？我提出，一个有经验的人在做判断时，往往已经能够在脑海中自动处理大量信息，但当个人状态发生波动时，原本有效的判断过程也可能受到影响。对方也将这个系统理解为一种尽量减少个人情感干扰、更多依据理性规则进行判断的方式。我进一步提出，系统可以尝试建立一个对现实运行规律的模型，但现实并不会必然符合模型的预期。当现实反馈与判断不一致时，就需要返回来检查和修改系统。这里讨论的并不是让 AI 拥有一个永远正确的答案，而是让判断依据能够被呈现、检验和修订。

在此基础上，我区分了两个容易混在一起的系统。一个是投资者本身的业务过程，包括选股、交易以及接受现实反馈；另一个是辅助她进行判断和决策的 AI 系统。AI 系统并不是替代全部业务活动，而是逐步承接其中一部分信息处理和判断工作。我在讨论中曾使用业务系统这个名称，随后调整为判断及决策辅助系统，以便把两者区分开。这个区分让我能够进一步说明：即使没有 AI，投资者原本也在持续实践、观察结果和调整判断；引入 Agent，是尝试将其中能够结构化、能够由系统承担的部分转移出来。

围绕业务系统如何运行，我提出了一个持续反馈的逻辑。投资者的实际操作、AI 提供的建议，以及市场产生的现实结果，共同构成后续判断和复盘的输入。当现实反馈与系统建议相符合时，需要分析哪些判断依据可能发挥了作用，进一步检查这些依据是否有效，并考虑怎样调整相应权重；当反馈与建议不符合时，则需要回顾错误发生在哪里、为什么发生，并围绕相关判断依据继续学习，再更新协议中的参数或标准。我特别强调，这里的学习不是学习如何操作 AI 工具，而是进一步学习支撑投资决策的知识和认识。这个过程既涉及规则更新，也涉及投资者本人对判断依据的持续理解。会议中形成的是这一机制的设想，具体怎样验证规则的有效性、怎样调整权重，还没有完成设计。

我们还讨论了系统建设与使用的先后关系。对方一度希望先把前端需要的东西做好，其他部分以后再说。我则说明，她原有的业务实践本来就在持续发生，AI 辅助系统应当嵌入这个过程，并随着实际使用逐渐改进，而不是把业务过程和系统建设完全割裂。讨论中我也尝试提出过持仓策略与风险保护的问题，但同时明确表示自己并不熟悉具体股票投资，只是在进行初步设想。对方的回应使我们没有继续沿着这一方向深入，而是回到怎样建设辅助系统的主题。这也明确了我在本次协作中的主要贡献：帮助理解需求、组织结构和建立系统建设流程，而不是提供具体投资策略的专业判断。

从系统逻辑转向实际操作时，对方反复询问应该使用什么工具。她已经接触过一些 AI 软件，但对于不同工具之间的差异、Agent 是什么、为什么需要多个 Agent，以及怎样开始使用，仍然存在困惑。我因此提出一个基本建设流程：先在本地建立项目文件夹，再建立 Markdown 文档，分别记录背景信息与需求说明；接着启动总 Agent，由总 Agent 组织不同功能模块或子 Agent，安排建设步骤、进度和重点；然后制作 MVP，进入日常运行和后续调整。我用代理记账等熟悉的概念解释 Agent，希望让对方理解它承担特定工作、接受需求并交付结果的作用。这里的多个 Agent 属于建设方案的设想，并不意味着现场已经建立完整的多 Agent 系统。

在工具选择上，我们存在一个明显的关注点差异。对方希望先用自己已经熟悉的工具，让系统能够开始运行；我则担心，系统涉及重要的投资判断，如果模型能力不足，可能无法充分理解复杂需求或完成建设任务。因此，我倾向于在系统建设初期使用能力更强的模型，并现场展示不同开发环境中的操作。对方坦言自己暂时看不出这些工具之间的明显差别，也希望能够先运行起来。后来，我提出可以先在自己的电脑环境中推进建设，待系统形成后再复制到她的电脑使用。这个讨论尚未形成经过验证的模型选型结论，也不能把使用更强模型等同于系统一定能够作出准确投资判断。

随后，我开始现场演示基础文件的建立。我在本地创建项目文件夹，准备 Markdown 文档，并向对方介绍 Obsidian 在本地文档阅读和呈现方面的作用。对方此前没有使用过 Obsidian，对 Markdown 文档也不太熟悉。我让她尝试借助已有的 Agent 工具下载安装所需软件，同时通过屏幕共享、飞书传递内容，让她跟着操作。这个过程中，对方多次询问文档应该放在哪里、需要复制哪一段、应该怎样向工具提交内容。演示出现了复制范围不清楚、任务线程需要重新开始等小问题，也反映出一个现实情况：即使系统设计逻辑已经说清楚，第一次使用的人仍然需要具体、可跟随的操作步骤。

在基础文档的整理过程中，我现场以投资者的第一人称，代拟了一份关于项目背景、已有经验、现实困难和建设动机的说明。文档尝试描述：投资者已经形成一定的选股、交易和风险管理经验，但日常信息收集可能受到注意力、个人状态和单一维度判断等因素影响，因此希望借助 AI 改善信息处理和辅助判断。我在口述过程中不断组织这些内容，并提醒对方，如果描述不准确，需要及时纠正。对方认可了部分核心表述。不过，这些文字首先是我为了帮助她澄清需求而提出的草稿，不能把草稿中的每一项经历、原则和效果都当作已经独立核实的事实。这个过程展示了怎样从口头需求出发，逐步加工为系统可以读取的背景材料。

我在这份背景材料中引入了《实践论》的思想，尝试说明人的认识如何在学习和实践中形成、经过整理成为自己的思想，再用于指导实践，并接受现实的检验。我特别讨论了从隐性经验到显性经验的转化：人已经拥有的判断方式，如果只存在于脑海中，AI 就难以稳定调用；如果能够把有效的判断依据提炼出来，形成明确的协议，并且在现实反馈后持续修订，就有机会让经验成为人机共同使用的资源。这里还出现了一个重要联系：人的认识需要更新，AI 系统使用的判断依据也需要相应更新。

在描述业务运行逻辑时，我继续使用输入、系统、输出的结构，把整个投资活动整理为一个可以持续更新的过程。输入包括主动选股与交易、Agent 提供的建议，以及市场的现实反馈；系统内部则需要判断反馈与原先预期是否一致，分析可能有效或者出现偏差的因素，并通过学习和复盘更新判断依据；输出不仅是某一次交易建议，也包括持续完善的协议文档。这个设计表达了一种设想：随着人的认识不断改进，AI 所依赖的决策依据也可以不断更新。不过，系统能否因此提高预测准确性，还需要建立独立的检验方式，不能仅凭一次判断符合现实就认定某项规则有效。

在进一步设计 AI 判断与决策辅助系统时，我区分了已经知道的需求和仍然不知道的技术方案。目前比较明确的是输入可以是股票名称或代码，输出要帮助投资者理解具体股票的情况，并形成可供核对的判断和决策建议。我在代拟需求时补充了几个呈现方向：长期关注的股票与新近进入视野的股票分别展示；除了建议，还要尽可能呈现重要判断因素及其变化，方便投资者根据自己的认识进行复核；如果未来能通过网站、图表或图片展示会更好，但第一版本只要能够清楚呈现内容即可。这里关于权重、展示字段和仓位相关建议的细节，仍属于现场提出的需求草案，需要由实际使用者继续确认。

关于系统内部怎样实现，我提出让 AI 承担更多方案研究和架构设计工作。现场代拟的设计要求包括：先寻找已有的有效方案，再从投资专业判断、系统架构等不同角度检查方案，并通过提出反对意见和识别问题的方式逐层完善设计。具体展开时，可以先呈现系统的几个关键模块，逐个说明每个模块需要什么输入、执行什么功能、产生什么输出，以及如何与其他模块衔接。这里还需要区分相对稳定的基础架构和需要持续更新的判断规则。比如文档组织方式、展示结构、部分运行逻辑可以相对稳定，而决策依据和判断标准则要随着实际反馈继续调整。这仍然是一套拟议中的建设方法，尚未形成经过测试的完整技术架构。

完成背景和初步需求材料后，我们尝试启动总 Agent，并进一步使用 AI 来检查此前的意图表达。我在开发环境中演示怎样为项目建立工作空间、选择模型、提交启动说明，并让 AI 阅读已经整理的材料。AI 随后生成了对项目定位、双层循环、现有基础和缺失信息的分析。我向对方解释，除了日常投资判断的运行循环，还需要不断改进投资认识和决策协议的循环。现场出现了一个值得注意的问题：AI 在分析过程中引用了我们无法对应的既往协作记录，并且一度混淆项目中不同人的角色。我发现之后当场指出并纠正。这说明，Agent 即使能够形成看起来完整的结构，也仍然需要人检查事实来源、角色归属和推理依据。

在这一阶段，我强调，我们虽然已经整理了不少内容，但对方真正用于投资判断的隐性经验还没有充分进入系统。尤其是具体判断维度、规则之间的关系、数据获取路径，以及怎样根据反馈调整系统，仍然需要进一步澄清。现场我也注意到，最终呈现什么样的信息才能令实际使用者满意，还没有完全说清楚。因此，继续向对方提问、帮助她表达已有认识，是当前建设工作的重要部分。我们不能因为已经有了较完整的背景文档和初步架构说明，就认为需求已经澄清完毕。

随后，我们讨论了进一步澄清意图的方法。我现场演示了一种通过 AI 连续提问的方式，让系统读取已有的初步意图，再逐轮提出问题，由人回答，逐渐把想要实现的效果、现实条件和具体需求说清楚。我还为这一过程准备了单独的记录文档，计划让澄清过程中产生的内容持续沉淀。按照我的设想，意图逐渐清晰之后，可以进一步整理为产品经理能够理解的方案，再交给后续的研发和 Agent 建设环节。这里值得保留的是，第一轮交流并不意味着意图已经最终确定，而是为进一步澄清提供了起点。工具名称和具体提问方式只是本次采用的操作示例，真正需要验证的是这种连续澄清过程能否让需求更加准确。

关于双方怎样配合，我们讨论了两种方式：一种是对方远程进入我使用的电脑环境，与 AI 直接交流；另一种是我把 AI 提出的问题复制到飞书，对方回答之后，我再将回答转交给 AI。考虑到同时远程操作可能影响现有连接，我们倾向于先通过飞书往返沟通。现场也介绍了远程连接工具，并请对方下载安装，作为可能使用的协作方式。对方在操作中完成了软件下载，但会议并没有显示双方已经通过远程方式完成整个建设过程。通过飞书进行问答，则是双方明确讨论并认可的近期协作办法。

会议后段，我们讨论了一个分阶段推进的时间安排。我提出，可以利用接下来两三天，通过持续问答把意图进一步说清楚，争取在周六左右完成这一轮澄清，再让 AI 提出初步架构。对方表示可以配合，也希望先看到一个能够使用的初步成果。我说明，这个系统涉及的内容较多，建设过程可能需要逐步推进，不必期待一次完成。对于当天的行动，我明确提出，会议结束后先把意图澄清过程整体启动，推进到需要对方回答问题的阶段，再把问题发送过去，收到回答后继续交给 AI 处理。这是会议中明确表达的近期推进安排，但不能据此认定后续工作已经完成。

在讨论推进节奏时，我再次强调，AI 项目建设中，意图和需求的清晰程度会影响后续方案设计。如果一开始没有充分理解用户真正想实现的效果，技术方案就可能反复调整。因此，我希望在前期投入必要的时间，把关键需求和约束说清楚，再逐步转入系统架构和开发。这也解释了为什么面对一个看起来能够直接交给 AI 的任务，我选择先通过对话了解实际使用场景，再组织背景、规则、系统关系和产品需求。不过，本次交流也反映出，意图澄清需要和实际操作体验配合，否则对初学者来说，概念和结构增加得过快，可能反而不知道第一步该做什么。

会议最后，我邀请对方回顾这次交流的感受。她提到，此前曾接触过其他人开发的专业 Agent，却一直不清楚怎样亲自搭建；今天的交流帮助她理解了部分建设方法，但同时也让她意识到，自己面对完整的设计和操作过程时，仍然不知道怎样独立开始。这个反馈很重要，因为它同时包含了两种结果：一方面，系统建设的整体逻辑变得更加清楚；另一方面，实际操作能力还没有随之建立。我回应说，可以先按照我们刚才的顺序反复实践：她表达想法，我帮助整理结构，再让 AI 参与意图澄清和小样建设。经过几次实践，她或许能够更加熟悉这个过程。这是我现场提出的学习路径，还不是已经得到验证的结果。

对方随后明确提出了一个超出单次系统建设的期待：第一阶段由我带领她完成，第二阶段她自己能够操作，第三阶段则希望能够带领别人去做。我认可了这个方向，并表示，通过两三个项目的实践，她可能逐渐熟悉这种建设方法。我还提到，整个过程中最复杂的部分之一，是理解一个人的意图及其内在逻辑，并把它组织成清晰的结构；后续不少建设工作可以尝试交由 AI 承担。对方也从产品经理的角度理解了这项能力。这使本次交流不仅涉及一个具体系统的建设，也涉及怎样让使用者逐步获得自主建设 AI 系统的能力。不过，这仍然是对方提出的成长期待，不能当作已经完成的培养成果。

这次交流还让我有机会在具体场景中表达自己的工作选择。当对方建议我通过线下开课等方式推广这类能力时，我没有沿着课程设计继续讨论，而是明确回应，自己目前更看重与喜欢的人一起做有意义、让自己感到欢喜的事情，也希望能够把眼前这个项目帮助对方做好。放在整个会议过程中看，我实际承担的主要工作，是听懂对方的具体期待，帮助她表达尚未充分显性化的经验，建立系统结构，并尝试组织 AI 继续参与建设。

回顾整场交流，已经得到初步明确的内容包括：系统要服务的具体场景、输入与输出的大致要求、判断规则需要协议化的方向、业务实践与 AI 辅助系统的区分、通过现实反馈持续更新判断依据的设想，以及先澄清意图再形成初步架构的推进方式。现场也完成了基础文件准备和部分 Agent 操作演示。但仍有多个问题没有解决：投资者实际使用的判断维度及其权重尚未充分提取，数据来源和获取方式尚未明确，怎样检验判断的有效性还需要设计，最终输出怎样才真正好用也尚未确定。后续需要在真实使用中继续验证，而不能将今天的初步结构当作一个已经有效的投资决策系统。